The original question

During the speaker panel at SCNA this past weekend, Chad Fowler (@chadfowler) asked, "How many projects fail because of the code?". Given the context, I assumed he was making the point that projects fail due to business issues, not code. The room was silent. While one might have assumed this meant the entire group thought it rhetorical, I concluded everyone agreed with Chad. Projects fail not due to code, but due to business issues.

The follow-up

Uncle Bob (@unclebobmartin) later did a quick twitter survey, which I and many others took part in. The results were overwhelmingly in favor of project failure being more attributable to business issues than technical issues. Bob felt many might take this to mean that code is not all that important in the long run and that craftsmanship, therefor, is not all that important either. Bob put together a well thought-out argument explaining why code is important and how it can, in fact, kill not only a project, but entire companies. Rather than reiterate it here, I strongly encourage you to read Bob's article, "The Cost of Code?" I agree with most of what Bob says in this article. The Cost of Code is high. I don't agree that all failed projects are due to code, but his points in support of that statement are no less valid.

Cause versus Responsibility

Smoking Guns

A man lays dead; a single bullet wound in his chest. A project fails; a mass of crappy code remains. Perhaps it is clear to you that a bullet killed the man. Perhaps it is clear to you that crappy code killed the project. Rather than enumerating other possible conclusions, given our substantial lack of evidence, I will conceded both points. The man was killed by a single bullet and the project was killed by crappy code.

Yes, technically, the project failed due to code.

Trigger Men

Our tragedies do not end there. We can no more stop murder by eliminating bullets than we can save projects by eliminating the need for code. While the bullet or the code may be the cause, they are both effects as well.

Somebody pulled the trigger.

In large projects, identifying one guilty party is commonly impossible not to mention grossly naive. In large projects, there are typically many humans responsible for the failure. If we were to perform archeological studies on the ruins of most projects, I am confident we'd find the failure to be between people. I am confident we would find it was a failure of communication. Not one, but hundreds or even thousands of failures; large and small. Lack of vision. Lack of clarity. Lack of cohesion due to lack of vision and clarity. Lack of clear expectations. Unclear status. Keeping quiet when we disagree. Raising disagreements in a non-constructive manner. Approaching debate as if it were battle. Inflammatory language that creates divides. Hiding our mistakes. Sending an email instead of making a phone call. Making a phone call instead of meeting face to face. Too much emphasis on delivery. Thinking speed and quality are diametrically opposed. Undervaluing the work of others. Apathy. The list goes on.

On a software project, code is critical. You can't have a software project without code. The worse the code, the greater the risk to the project. Bad enough and the project will fail as a result of the code. Significant enough, and the company will fail as a result of the project.

But don't forget it is we who write the code.

It is we who pull the trigger.