Code is the Culprit! Always?

Write for InfoQ

Multiple reasons can be quoted for the failure of software projects. Some projects fail because of bad requirements, others due to cost and schedule overrun and few simply due to bad management. If we do a root cause analysis, would all of the failed projects lead to bad code as the main culprit? Always?

Uncle Bob strongly believes that the cost of bad code is too high to make a project fail. According to him,

I do know of projects that have failed because of the code. Indeed, I know of companies that have failed because of the code.

According to Bob, the reasoning is simple. If the cost to maintain the code exceeds the project budget then the project fails and if the cost exceeds the company budget then the company fails. Taking the other extreme Bob suggested that if the cost of code is close to zero then no project would fail.

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.

However, not everyone agrees with this idea.

When this question was posted on twitter, most people agreed that business issues were the leading causes of project failure. Alex Chaffee suggested, that bad management and bad requirements cannot be outdone by good code

If you have bad requirements and bad management then even free, instant code can't save your business. If you could instantly deploy a flawless version of a useless product that nobody wanted, and then kept rapidly iterating more horrible versions of that crappy product, then you would still eventually run out of money and time and reputation, and your project or business would still fail.

Likewise, James Iry mentioned that bad code is just one of the reasons that a project could fail. According to him,

Free code certainly enables a company to more rapidly iterate, but if it just iterates through bad ideas, or good ideas that it can't sell due to bad marketing, or it sells well but creates an overly heavy cost structure in facilities or management or whatever then the company will eventually fail.

Michael Dubakov suggested that projects fail if they do not provide the right solution. He mentioned that if the code is clean, it would be easy to re-factor it to get to the right solution but it does not imply that good code is the right solution. Michael suggested,

You can create an absolutely beautiful architecture with the cleanest code in the world. You may have 100% test coverage, complete separation of concerns, flat hierarchies and methods without boolean arguments. You may have all that beauty, but still fail miserably if the program does not solve user’s problems efficiently.

Michael Norton, added that almost all project failure root cause analysis would lead to people. According to Michael,

If a project failed because it solved the wrong problem, the project failed because the people involved misunderstood the problem. If a project failed because of poor quality code (and some do), it failed because the people involved consorted to write code poorly.

Thus, though nobody undermined the importance of clean code, however not everyone agreed that bad code is solely responsible for failure of a project. What are your thoughts?

Related Topics:

• Development
• Architecture & Design
• Culture & Methods
• Code Analysis
• Agile
• Software Craftsmanship
• Failure

We protect your privacy.