Places To Go
News and Reviews....
People To See
Places To Go
Thursday, April 02, 2009
I noticed an article on Wired about robots stealing jobs
and got to thinking about outsourcing, this down economy and all the conversations I have had (calm and otherwise) about jobs moving offshore.
Ultimately I don't see any reasonable way to stop jobs from following a well established lifecycle that ends in automation. If you take any task that is currently done by a robot you can probably look far enough into the past to find a point in time when it was cutting edge technology and either a skilled technician or fine artisan performed the function for premium pay (Dot Com boom html programmers for our purposes). As time goes on the task or job becomes well understood, well documented and even taught in all the schools around the world and since the task is still highly paid (that has eroded by now) it attracts alot of people who want that job. Then the task moves toward commodity and the formerly highly paid technicians and artisans have chosen from exactly two courses of action. They have either moved on to the new cutting edge thing or they are moaning about the erosion of their value in the marketplace (blaming the marketplace of course and never themselves). Then it gets worse for this latter group since eventually (and eventually comes quick in the 21st century we have found) the commodity task is recognized to be cheaper to be done offshore. For high tech India and Egypt are hot along with many other locals (I just have most of my experience with offshore teams in these countries). The formerly high end task is drone work now and can be done by a bright student from any continent so the work flows to where it can be done most inexpensively. This is the point of maximum complaint by those who remember making $100 an hour for doing this task. They then stop paying attention just in time for that task to be automated by a program, system or abstraction layer so that no one would ever pay for it to be done by hand ever again. At this point you could probably hear people in the offshore tech districts complaining. This is progress. It is painful, but it is also inexorable, you cannot stop it and you shouldn't try to slow it down. Instead you should be like the other group of highly skilled technicians and artisans and find the next big thing and constantly hone your skills. This is absolutely doable in our high tech field.
I know this post will come off as callous to some and I am sorry if I am too blunt for some, but especially in times like these we have to stop looking back wistfully at the past and grab our books and browsers and dig in to invent and shape the next revolution. I personally think that energy and the technology that helps with conservation is the next big thing, but there is still lots of room elsewhere. If you view the lifecycle of a job as a good thing you see that it has freed us from farming our own food, making our own clothes and has allowed so many of the things that are best in our civilization. Embrace it or be marginalized.
Finally my apologies to those stock boys out there who have had their hopes and dreams shattered by R2D2.
Wednesday, April 01, 2009
In my business we deal with companies that are by their very nature risk averse and hence I only play with the newest tech for our internal projects, the occasional customer emergency and in my free time. Even so I have watched Microsoft's Azure pretty closely and while I am confident that eventually we will take cloud computer for granted as we do dynamic web technologies now, I am also pretty sure that we still don't know exactly what and how the real impact will take shape. Without clear SLAs and Pricing I just can't gauge how reasonable it will be for a customer of size X with application of type Y to opt for Azure or any other cloud computing platform. That belief also drives me to think that the Open Cloud Manifesto is at best irrelevent and at worst a major impediment to getting where we want to go. If we don't know what the best end state will be because we have yet to really evolve the technology in the real world then how can a group of people (any group) really hope to lay out the rules of the road. There isn't a road built yet after all.
It has been proposed that guidance is needed to ensure that solutions are "open". I can only assume that this means that they want code deployed on vendor A's platform can be moved to vendor B's platform unchanged (the classic case of wanting to not gamble on vendor lock in). While that is not specifically stated, I just don't see any other interpretation that makes sense.
Time will tell, but I suspect we are several years of market testing and evolution from a point where we can even begin to have this conversation intelligently.
To read more on this topic I will point you to blog posts by Chris Auld and Michelle Bustamante. I must say that I agree with them for the most part.
Friday, March 27, 2009
I promised to upload my presentations from last month's New Hampshire Code Camp so here they are...
I delivered the keynote address for the event covering how to survive as a developer in this depressed economy.
NH Code Camp Feb 2009 Keynote.ppt (592.5 KB)
I also got to debut a new session on How to prevent project failure and a follow on called Project Specification for Survival and Profit. The reviews on that second session have caused me to combine them a bit and create what I think is a single, better session that I am going to be presenting at the Boston Code Camp tomorrow.
How to prevent project failure v1.ppt (559.5 KB)
Project Specification for Survival and Profit v1.ppt (464 KB)
Sorry for the delay in posting, lots of travel lately, but that is not unusual for me...
Wednesday, March 11, 2009
Tuesday, October 28, 2008
I am here at the PDC in Los Angeles this week and have heard quite a bit of grumblings about UAC. The MS employees on stage and elsewhere are basically saying that UAC is a necessary evil so that clients do not become vulnerable due to unauthorized software install (and other admin level actions). The developer side of this argument is that UAC is a blunt instrument like a security guard in your house that keeps asking you for your passport. You can’t argue that this guard will make your house safer, but he is also going to drive you crazy until you decide to fire him altogether. That is what we are seeing in the field with so many people simply shutting off UAC.
Now that Windows 7 is in sight it might be too late for my suggestion of how we might get the best of both worlds relative to secure software install. My idea is that when you go to install software you should be presented with a Capcha style challenge which ensure a real person is at the helm. Once that Capcha dialog is completed successfully the OS should track that this install is authorized and therefore exempt from future challenges since we know this is not malware (or at least not secretly installed malware).
Since this idea just came up this morning I am guessing I am missing some aspects to this approach that are problematic, but on first look I think this approach could help make things more secure while not destroying user productivity.
If you agree then bring this suggestion up to the people you know at MS. That is what I am going to try to do later today.
Thursday, September 18, 2008
I have worked on many software development projects, both commercial and line of business and every single time I talk about optimization to a developer they always jump to the same conclusion. They think I mean speed of execution. I grant that the majority of the time when people talk about optimization that is what they mean, but it is not 100% of the time correct. Often I care more about the maintainability of an application especially if I know it is destined (or doomed) to morph quite a bit over the next year or so. In these case it is often an application that will be used by employees and many of the standard assumptions do not apply.
Take our Intranet for instance. It is only used by employees and our closest contractors. We use it for tracking customers and projects, for forecasting sales and even timesheets. I don't care if it is 5% slower, I want it to be adaptable since we are an agile company. I don't mess with the code every week or even every quarter, but the code is written in such a way that I or any other developer on staff can go in and very quickly add a field or add other features very quickly. We didn't sacrifice security (that would be unacceptable), but we did forgo the multi tier architechure and stored procedures for parameterized queries. This is a sin in many circles, but if the application's backend is single use (only one application) then there is much less advantage to all the abstraction. I am sure the arguments will flow down on me now, but I see the same drive for complexity without purpose (real advantage I mean) in the Java world where code portability is everything and yet almost no one ever avails themselves of that costly feature.
The next time someone asks you to optimize something ask them if they mean for performance or maintainability and let the funny stares begin...
Wednesday, September 17, 2008
Life changes pretty fast sometimes when you aren't watching. I woke up today and realized that much more of my work is involved in keeping projects on the straight and narrow and much less is spent making database fields show up in the right place and with the right user access set. For that reason I am changing gears and will leave most of the technical details of our projects to Duane Laflotte
. He does it better on his blog anyways...
That having been said you can expect me to pick up the blogging pen again, but this time I plan to write about management of technical projects including things like sales, process engineering, fixed bid proposal generation and the other things that I wish five or ten years ago I had found a blog to read. I also will likely talk alot about commercial vs. business programming and the impact of new technologies on a technical consulting practice. If this makes some of those that followed my blog leave then I am sorry, but I do think that this blog will be better for the change (at least now I will feel like I can vent here a bit).
See you soon.
Monday, April 14, 2008
I have recently finished my last presentation here in Cairo at the EDC 2008 and wanted to start getting my presentations uploaded for all those who were asking about them. To make things run faster I am uploading them each in their own post especially since the AJAX example hasn't been packaged yet.
I covered Indexing in SQL Server including what works and what does not work. I was very happy that my friend Mohammed Meshref from the Microsoft SQL Server team was on hand to both help and to be picked on ;)
EDC08 SQL Indexing and Perf Draft 2.ppt (546.5 KB)
Friday, March 21, 2008
I have often thought about the mindset required to be good at the security game. I hang out with Duane Laflotte alot and he has the penetration tester mindset which lends itself nicely to security even when you aren't trolling on the dark side.
But it was an article that got picked up on Slashdot today about Bruce Schneier's
thoughts on this subject that revived the thread for me.
I have what I think is an interesting twist on this perspective in that I believe that the only way to teach what Bruce is holding out as unteachable is what I believe taught me to think this way. When I grew up I didn't think the way Bruce Schneier thinks. But I do now. The reason I believe is the military. When the Army trains infantry leaders it teaches them how to defend while looking always for ways to attack. The mild mannered programmer is taught to build, but if part of that training put in their mind that to be successful they had to tear down the abilities and infrastructure of the hackers then we might get a different result.
There is nothing to make you think like a hacker than to stand on a hill and realize that you are defending it at dawn and if you fail you and all your soldiers die. It also makes you want to get that unfair advantage and lay traps for the enemy. During a major training exercise in Germany I put soldiers in foxholes with signal mirrors and had them flash the enemy armor to draw fire while our vehicles flanked and destroyed them.
So I think if you want to be a hacker and you don't think like one I think the Army recruiter would be happy to help get you trained...
Wednesday, March 12, 2008
As I said a couple of days ago, I am speaking again in Cairo in a few weeks at the EDC. I have arrived on the topics that I am presenting. While these are still subject to change it looks like:
- A session on AJAX
- A session on Commercial Software Dev (vs. Business development)
- A session on Indexing Optimization in SQL Server
I am really looking forward to seeing all my friends and again want to thank Waleed Abdelwahab
for pushing me to revive this blog.
See you all soon!