Something's Fishy (updated)
Part I: Continuums and False Dichotomies
On another of my posts, there were the following pair of comments:
There are many people who do get into our field purely for money. The sad thing is that they’re allowed to. There are not enough sufficiently hard courses that weed out the less dedicated ones available on the university/college level. Same could be said of the HR people who are not able to distinguish wheat from chaff…
I don’t see why that’s necessarily a sad thing…The fact is that the majority of programming tasks aren’t actually that difficult. They don’t require a superstar in order to get done…
I agree that many programming tasks are not difficult. I am not convinced we have found a good way of predicting which tasks are difficult and which are not, which require a cut and a paste and which require some careful thought to avoid breaking something else or adding cruft to code.
I don’t think we do a very good job of dividing up work on a project such that the people with the least experience are protected from damaging the code. But that is just my opinion. I may be wrong.
I am much more confident when I say that we have to be very careful when we set the bar for the minimum standard needed to ship software. The choice between (a) employing people who aren’t particularly dedicated and would fail anything remotely resembling challenging courses in computer science and, (b) hiring “superstars” is a false dichotomy. There is such a thing as someone who is competent and professional enough to pass tough courses. Someone who won’t get confused if you ask them to keep abreast of developments in their field.
Guillaume seems to agree
In many other fields there are tough courses. MBA programs are often touted as separating the wheat from the chaff. Yet we don’t assume that every MBA is a superstar in business. We do assume they have a baseline of competency. Likewise Chartered Accountants do not tolerate people taking a lukewarm attitude towards their field. But nobody would describe every accountant as a financial wizard.
There’s a continuum of talent, and we can raise the bar above the gutter without leaping from mediocre to world-class in a single bound.
In any business situation, it’s prudent to be wary of people who put their own selfish interests ahead of the business. So it’s fine to avoid people who want to learn to use the latest bauble on your dime. But again, let’s not establish another false dichotomy: people who are curious about programming and eager to learn are not automatically disinterested in shipping solid code using conservative strategies.
The most important thing is to establish the baseline competency required for the job and find the people who meet it. We don’t lower the bar to match whomever is available when we are looking, and we don’t assume that our choices are always binary (Superstar vs. Mediocre, Passionate vs. Pragmatic, Java vs. Ruby).Part II: Something is still fishy
For a solid grounding on how to successfully develop software, start with The Mythical Man-Month: Essays on Software Engineering. It is one of the most important books ever written about developing software, from the small to the large. Read the book that spawned the expression, “There is no silver bullet.”
There is another way we can misinterpret Guillaume’s comment. Many programming tasks are not difficult. True. But that does not mean that all programming tasks are not difficult. Furthermore, I have experienced a paradox: sometimes when a good person works on an easy task, they see things in the easy task that an average person would miss.
An average person might copy and paste code all day. A good person might refactor to eliminate duplication. Of course, that means the good person can do far more of the easy work than the average person. But more importantly, the code base is forever improved, its friction has been lowered.
The existence of easy tasks in programming can lead us to believe that a programming is a relatively unskilled trade. When we examine the pieces on their own, we might believe so. My question is this:
If anyone can do it, Why do we as an industry stink at it
? Although each piece seems easy, the whole of completing a successful project on time and budget with acceptable quality and good long-term cost of ownership is elusive.
Now I know that Joel Spolsky and everyone else at Microsoft will tell you that software is ridiculously high quality compared to something-or-other. And with auto-widget-building wizards and AST-bending IDEs and memory management, today’s programmers ought to be ridiculously productive.
I admit this is anecdotal, but I’m hearing a different story from my ex-colleagues and ex-clients out there: projects are late, bug lists are long and getting longer, and a lot of companies are scrutinizing their IT ROI and getting very Scrooge-like about starting new projects in-house.
They just aren’t happy with the results they’re getting.
Now maybe this has absolutely nothing
to do with programmers. Maybe it’s all about requirements and waterfall and managing expectations. Maybe it’s all about looking at writing code and realizing that getting ’er done today with a few minor warts is more important than getting ’er done tomorrow with no bugs. (Or worse, tomorrow’s code is even buggier because it features an abstraction of a framework plugged into a component organized in a service architecture, and there’re so many moving parts that nothing works properly.)
Or maybe this has nothing to do with the problem-solving, hold a complicated thing in your head, visualize all the ways it can go wrong so you can program defensively part of programming. I buy that. I buy that maybe we have to be better at writing programs for people to read. I buy that we have to be better at testing our code. I buy that we have to be better at all sorts of software development skills like analyzing requirements.
It could be that programmers on the whole have all of the skills needed, and that our problem is we just haven’t found the right formula for harnessing their power, for getting them all to march in lock step towards project success.
Maybe we programmers are doing a fine
job and there’s no need to be better at it. But somehow something
isn’t right, and throwing more people with fewer skills at the problem doesn’t seem to be working.