In a panel at #scna yesterday, @chadfowler asked the question: "How many projects fail because of the code?" I think the point he was trying to make was that the primary causes of project failure are business issues, not technical issues.
I posed this question on twitter earlier today. The responses came quickly, and virtually all of them agreed that business issues are the more significant causes of project failure.
It's certainly true that projects fail because of cost, requirements, schedule, management. etc. It's also true that we seldom trace the cause of failure back to something as mundane as code. So Chad's point, if that's what it was, certainly has merit.
The conclusion that we might make from this is that code just isn't very important in the long run, and the the craftsmanship movement might just be a load of Yak Shaving. Indeed, Chad asked us to consider just that in his talk at #scna. If we follow that reasoning, then we should decrease our emphasis on technological prowess and skill, and increase our emphasis on business, requirements, budgets, schedules, and management.
Before I counter this argument, let me say that I do know of projects that have failed because of the code. Indeed, I know of companies that have failed because of the code.
This isn't actually very difficult to believe or understand. We all know that when the code is a mess, it becomes more and more costly to maintain and improve. If that cost exceeds what the project can afford, the project fails. If that cost exceeds what the company can afford, the company fails. In the cases that I am aware of, this is precisely what happened. The code was simply too costly for the business model to support.
So let's try a simple thought experiment. What fraction of projects would fail if the code was infinitely expensive to produce and maintain? Clearly all projects would fail because the code would be too expensive for any finite business model to support.
OK, so what if the code cost nothing to produce and maintain? What fraction of those projects would fail because of the code? Again, the answer is clear. No project would fail because of the code, if the code costs nothing to make.
What does it mean to cost nothing to make? It means that you would have the code you needed the instant you needed it. The code would simply be there, instantly, fully functional, free of defects. Any time you needed a change, the change would instantly be in effect, fully deployed, fully operational.
So let's say you are thrown into a cave by some thieves. In that cave you find a old beat-up PC jr, complete with the IR chicklet keyboard. You pick up that keyboard and rub a smudge off the enter key. Wooosh! a genie appears on the screen and grants you the ability to have zero cost code for the rest of your life! Would any of your projects ever fail from that point on?
Remember, nobody else has your ability. Nobody else can produce the code they want, instantly, and without defect. Nobody else can make and deploy changes in zero time. So you have a tremendous competitive advantage. Is there any way you could fail? I think my dog Petunia might fail, but anyone smarter than that should become a multi-trillionaire.
If we had that magic PC jr, there wouldn't be any schedule or budget issues. The cost of mismanagement and/or bad requirements would be close to zero. So all those things that cause projects to fail would become irrelevant.
But we don't have that magic PC jr. Code does cost money to produce and maintain. But if I, as a craftsman, can invoke a fraction of the power of that Genie to reduce the cost of producing and maintaining code, then I simultaneously reduce the cost and risk of mismanagement, of bad requirements, of tight schedules, and of tight budgets. By reducing the cost of the thing that's being managed, we reduce the cost of error and increase the chances of success!
Why is it that projects fail due to bad requirements, bad management, bad schedules, and bad budgets? They fail because the cost of error is huge. Why is the cost of error huge? Because the cost of the code is so horribly large. If code cost nothing to produce, the cost of error would be close to zero.
This realization has not been lost on the business community. They tried to solve it by reducing the hourly rate of programmers. They set up horrifically expensive and risky mechanisms in order to hire programmers who lived half a world away in a wildly different culture. They faced the issues of time zones and languages, and cultural mismatch in order to reduce the cost of code. They did this because they understood that the it is that cost that drives the cost of management error. They did this because it is that cost that makes projects fail.
Unfortunately this strategy didn't work as well had been hoped. Some folks have made it work; more or less. But the majority of the off-shoring efforts have been disappointing. And so the cost of code remains high, and therefore the risk of error is also high.
And that brings us back to the question at hand. How many projects fail because of the code? The argument above suggests that all failures are a direct result of the cost of code. How many projects fail because of code? All of them!
More importantly, what is the single most effective way to increase the chances of project success? Is it improving requirements? Management? Schedules and budgets? All those things would help, but they are all secondary to the thing that truly drives project failure: The cost of the code.