Maybe I'm just a cranky old man but it seems to me that software development just ain't what it use to be. I'm not talking about standard consumer grade software which seems to be getting more and more interesting albeit at a much slower pace than I would have predicted 10 years ago, I'm talking about the software that makes the world go `round. The software you run your business with. Enterprise level software.
Robert X. Cringely did a recent column with a similar bend (The Truth About IT Consultants: Some are great but most are not. April 18, 2008) in which he points out what seems like a no-brainer; Everyone is not created equal. While I don't think his article is 100% on target, it does hit on a few main points which I think are obvious but apparently are not.
The first point which I've brought up numerous times in the past is that software developers are not interchangeable parts. There is a vast difference in abilities from one to the next and the gap between the top-of-the-heap and the middle-of-the-road seems to be growing larger and at a very rapid pace. This is because there isn't a carrier path for developers. Old developers are like baby pigeons, you just don't see them. Once you have reached a certain level as a developer you're expected to go into management or start a company or like so many others, find a foothold and dig yourself into a technology or system that no one else wants to support.
The truth of the matter is I am a much better developer today than I was 10 years ago. I'm not a better coder, but I am a much better developer and this is why: I know why I do what I do. 10, 15, 20 years ago I wrote code because it's what I was born to do, and without being too modest, I was quite good at it, but then something happened. Instead of worrying about how to make a tighter loop or a more robust library I started to think about why I was writing the code in the first place. I started to think about the people who were paying me to write it and what it was that they wanted. What I realized was that none of them wanted a tighter loop or a more robust library, they wanted to solve a problem or gain some insight to their business or streamline a cumbersome process, but there was never a case where they wanted sexier code.
In my entire career I have only come across maybe 1/2 a dozen developers who actually get that, and coincidently enough they are the best 1/2 a dozen developers I've come across in my entire career. Unfortunately they are treated almost exactly the same as your typical middle-of-the-road developer and their rare talents are not truly appreciated until they have moved on. Sadder still they usually do the work of 3 or 4 lessor developers but rarely see more than a few dollars difference in salaries. Despite that they still do the best job they can because they care about what they do.
Another point I'd like to bring up is the danger of hiring a poor developer. One of my many rules is that adding a good developer to a 5 person team can boost productivity by 10-20%, but adding a bad developer can reduce productivity by 90-100%. Everyone who has been in the industry for any length of time knows this to be true and can probably point to very specific instances of this in their past. What confounds me to no end is why, with knowledge in hand, do people continue to think that they are the exception to the rule? I'm astounded at the number of times I witness management on an already tight project attempt to cut corners by staffing it with down right incompetent people.
And while I'm on the subject let me bring up the importance of the developer actually understanding the business that they are developing for. A typical interview for a C# developer may include questions comparing the use of String.Format to StringBuilder or the proper use of a Command Pattern. While this may be slightly important I would argue that any developer worth his salt could quickly adapt to any language and / or platform quickly enough and with enough depth that these kind of questions are of little value. Some forward thinking shops may try to heuristically gauge whether or not a candidate may be able to work well as part of the team. This is an important metric but is little more than guesswork and something that most developers who work with other people can get a feel for in 5-10 minutes. What no one appears to ever interview for is industry knowledge which is the one thing that is hardest to come by. Just because you've been a DBA for accounting firms for the past 10 years does not mean you have any understanding of the needs of a DB for patient care. Not that you couldn't learn, but it's much harder for a developer to learn a completely different industry than it is to learn a new programming language or toolset.
This is an issue that has plagued me for many years. In professional sports, the top players a clearly differentiated from the average players, and the poor players are eliminated completely. In software no such delineation exists between the best and the worst and even the truly terrible continue to thrive in the marketplace.
TTFN