Ever since I started writing software professionally, I've noticed this bizarre but very widespread tendency to invert strategy and tactics when looking for a developer. What I mean is starting a software development project not by discussing the goals of the software, what is to be invented or how it will make a current task faster, cheaper and/or easier. Instead, the person running the project, often with little or no personal experience with software development, skims the surface of the software development periodicals and Web sites, learning little more than buzzwords and acronyms. Then they make logically flawed decisions about what is needed in terms of languages, platforms and development environments. Having pre-selected the specific technologies to be used in building the software, the unwise project lead then sets about finding a developer who evangelizes those technologies.

I suppose this wouldn't be a problem if so many programming projects didn't fail. It's an astonishingly low success rate, 31% as of 2003 according to the Standish Group. So if more than 2 out of 3 software projects fail on average, you would think there would be a higher value placed on finding developers that have proven track records of delivering useful, usable applications on time and on budget. But whenever someone asks me for a referral, they're not looking for a programmer that has a successful track record developing accounting systems, real estate software or social networking widgets. Instead they ask if I know any Ruby on Rails, .Net, Java or PHP developers. (These four seem to be the trendy requests at the time of this writing, but they have changed over time.)

To say that this is putting the cart before the horse is a poor analogy. It's more like dropping a used car salesman into Fermilab and expecting him to discover cold fusion within a few weeks. Barring incredible luck or divine intervention, it's just not going to happen. 

If you're dealing with an experienced developer, it doesn't really matter what language or platform is needed. They'll be able to identify the needs by talking to the stakeholders, researching the available technologies, and learning any desirable, new technologies in stride. But if you're dealing with an evangelist, it's a roll of the dice. It's possible that the evangelist has used many other languages and platforms successfully in the past, and became an evangelist because they have found genuine value in the technologies she is now using, and is enthusiastic about sharing her discovery with others. But there are probably many more flag-waiving zealots out there who have been persuaded by the hype surrounding the technologies they're recommending, but have little experience outside a narrow field of work. And if you just skimmed the surface of developer literature, how would you know whether the programmer you're considering can deliver or not?

And even this wouldn't be much of a problem if programming didn't resemble so many other areas of business where hype is king, because hype drives sales. Many technologies have experienced a tremendous adoption rate not because of utility, efficiency or technical superiority, but because the company selling those technologies hired a really persuasive propagandist.

Experience with the kind of data and concepts involved, including the business model itself, is key to successful completion of a software development project. I often refer clients to other developers when I know that the other developers have relevant, deep experience in the specific domain of knowledge needed to complete the project. My past attempts to take on projects too far outside my experience have just turned into money-losing propositions for the companies I've worked for. I'd rather not repeat those experiences.

So the next time you want to hire a developer, please think long and hard about what matters most: Finding someone who agrees with uninformed preconceptions about particular technologies, or finding someone who can successfully implement your vision. The two are rarely the same.

Thus spake the master programmer:

"A well-written program is its own heaven;
a poorly-written program is its own hell."

- The Tao of Programming : 4.1