People solve problems, not processes. I know this sounds like I’m trying to make an obvious observation sound like some brilliant and ironic commentary on mankind. But after you’re done rolling your eyeballs, hear me out.
Throughout my career, I’ve been dismayed and disappointed to encounter regularly customers with huge software development messes left unfinished. Incidentally, that’s not to say that I haven’t been responsible for any. Like everyone else, I’ve learned from mistakes and improved over the years. But as I consider the landscape today and assess how it is that organizations continue to struggle with domesticating the IT animal, it seems to me that many of them confuse people with process.
I see evidence of this in the job market for contract software developers nearly every day. To begin with, there is typically a lengthy and detailed list of requirements for expertise with this language and that technology. Next, candidates are frequently subjected to pre-screen quizzes and online assessment testing to determine their knowledge of programming minutia. My contention is that this only confirms the process and not the person. In other words, the person can string together these particular commands without referencing the help file. Ergo, they must have done this before. Ergo, they are a knowledgeable programmer.
Another example is the reliance upon and prescription of complicated specifications and/or rigid methodologies. Don’t get me wrong here; I think standards and best practices are a good thing. However, rigid and complicated processes tend to prevent people from seeing the forest through the trees, as the focus necessarily shifts from the project’s goal to making sure we didn’t skip step number 12 in section 2 of the first volume of the third edition of the Hitchhiker’s Guide to Project Implementation (with apologies to the late, great Douglas Adams).
If it sounds like I am not sympathetic to the plight of project and hiring managers, I am. If it sounds like I am condemning the use of accepted methodologies or detailed specifications, I am not. What I am saying is this. Most of the time, a great process will not save you from bad people. But most of the time, great people will save you from a bad process.
This brings me full circle to the impetus for this blog entry. The process of selecting the right software developer or consulting firm to undertake a major project is very difficult. I have walked many of those mine fields and passed the corpses along the way. I am a firm believer that high quality software development requires programmers who have some amount of subject matter expertise. The one nugget of practical advice I’ll offer here is to search for a consultant who can tell you something non-technical about your project that you didn’t already know. Then you’ll know that you have someone who has more to offer than stamping out lines of code. If you ask a user what they want a program to do, they will generally struggle to articulate an answer (it’s a rare and beautiful thing when they can, believe me). When they actually get their hands on something, however, you will not be able to shut them up! They will generally be more than happy to tell you what’s good, what’s not, and what’s missing. The best programmers will know much of this ahead of time and, by all means, be able to adapt, overcome, and improvise. Otherwise, you could very well become one of the many who have uttered the phrase, “You built me what I asked for, but that’s not what I want!”