# Code is the Culprit! Always?

| by Vikas Hazrati 0 Followers on Dec 14, 2010. Estimated reading time: 2 minutes |

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?

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

## Get the most out of the InfoQ experience.

### Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Of course due to the people involved by xin du

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.

Its not always code

Project could fail due to many reasons, unclear vision for example. Doesn't always have to be code. If project manager is not sure what they want exactly and get it started somehow, that project could fail miserably. In cases like this and many other, I would say the sooner it fails the better.

Bad code is a symptom of a failing project

Not the other way around ;) The question is how come there is bad code? What allowed it to be written and exist. How come no one stopped writing bad code? Bad code is the result of a failing IT project like ruble is the result of a bad bridge building project. You can blame the ruble but your looking at the wrong part of the process.

In any case you can have successful project and company with bad code e.g. have a look at Microsoft ;)

Contracts are not based on codes, they are based on requirements....

As we all know a Project fails or succeeds according to three criteria. And as we all know these are scope, schedule, cost.

In software development projects :

Scope is the requirements. You should understand, identify, track, and satisfy the requirements (ofcourse within the budget and schedule)

If requirements are not clearly understood, identified and tracked, your project will fail before the coding phase…. no matter how good or bad your code is/will be.

If your requirements are set, handled successfully, satisfying those requirements will be the next step. And if your product doesn't satisfy the requirements it will fail too. Bad coding may be just one of the reasons for this failure. Other reasons may be lack of management ( risk, time, quality, people, cost, etc.)

Reasons of bad coding may be:

Insufficient domain know-how
Learning the tools/libraries/language while coding
Using wrong architecture
Reducing the quality of the code to stay within the schedule,
Reducing the quality of the code to stay within the budget,
.....
.....
.....

So we can't just say code is the culprit

Pointless debate

I find this debate overly ridiculous. The arguments used against Uncle Bob points are fallacy. This is like arguing that many people weren't only dying young because of bad eating habits, but also because they can jump over the bridge.

It is obvious that addressing the wrong problems (jumping over the bridge) can lead to project failure. This is simply obvious. There is no need to write a dissertation about it! I also can't imagine how this would happen with iterative and incremental development because the wrong path would be quickly visible. Of course, some projects might fail because of such reasons, but I can only imagine this happening in very dumb organizations.

On the other hand, I think the reason why there are so much jobs in our industry is because of the huge amount of rotten code that must be maintained. This is not obvious since it still goes on.

Uncle Bob has been repeating the same story over and over, but it seems like it still need to be repeated some more. Professionals who care about their craft are still an exception out there.

Usually not

I've seen successful projects with terrible code. They are unmaintainable in the long run but they meet the needs of their users. I've also seen projects fail with really good code.

Q. How does really good code fail?
A. When it solves the wrong problem or addresses the wrong need.

Determining the requirements is the most important part a software project. Don't assume I am talking about waterfall. This determination can be made by implementing a system and then refining it until it meets the requirements. Bad code is a major issue but the reality is that it doesn't really matter how good the code is if it doesn't meet the needs of it's users and you need to know what those needs are in order to have a hope of meeting them.

In my experience the biggest problem I face is a lack of clear requirements. This isn't just isolated to new work either. I often am faced with code that pretty obviously doesn't do what it should but lacks any documentation of what it should do. We can only be reactive in such situations and this leads to constant fixes that often break other things that need to be fixed breaking yet other things etc.

I don't understand

How the cost of a misunderstanding of the requirements can be so big when the code is lean and simple? The simpler the code is the cheaper it will be to embrace change. Using small iterations and customer feedback, how can any project go so wrong?

If everything breaks when changing the code to meet the requirements, this means a lack of unit tests, decoupling and cohesion in the code.

Re: I don't understand

How the cost of a misunderstanding of the requirements can be so big when the code is lean and simple? The simpler the code is the cheaper it will be to embrace change. Using small iterations and customer feedback, how can any project go so wrong?

You aren't done until the application meets the requirements. If you are talking about how you get to completion, I don't disagree. If you are suggesting that you can ship a product that doesn't do what is needed and that's OK because you can easily change it, you are really talking about a second attempt because you have already failed. You can keep repeating this process but you are unlikely to successfully complete a working product until you actually know what it needs to do.

Also, you are vastly oversimplifying the issue. I'm not sure if that;s intentional. If you write a really great application that does 2 things (wrong) and what was needed was something that does 12 things (right), you are really far from success. Another factor that is missing from this is time. How long do you have to meander around trying to happen to fulfill unknown requirements?

If everything breaks when changing the code to meet the requirements, this means a lack of unit tests, decoupling and cohesion in the code.

You are missing the point. I'm not talking about crashes or other 'first year of professional coding' issues. I'm talking about breaking functionality. If you have an application that does X when a certain range of values Y is input and it's reported to be wrong for some subset of Y, is it wrong for all Y? Who knows? Do you change it to do Z for all Y or just some? If it's the latter, which ones? The range might be millions of values. The person who discovered the error might now how a change to the behavior will affect other downstream consumers of the data (which you may or may not know exist.) All you know is what the code does today. Which parts are right, which parts are wrong and which parts are sometimes right and sometimes wrong are unknowns. There's so much code out there that doesn't work properly and nobody even knows because they accept whatever it does as correct and it 'passes it's unit tests'.

In a lot of ways, good requirements are often more valuable than working software. They are also much harder to come by. Case in point, DOS was created by a developer who merely had the manual for another operating system.

Re: I don't understand by Mr Magoo

Still struggling to see the information being conveyed here that is not patently obvious? Or is that patent still pending?

Perhaps a lot of fallacy though?

Projects fail for a wide variety of reasons. RESEARCH (rather than opinion) has suggested that a great amount of the time it is a project management/management failure.

Random refs with further refs embedded:
www.projectperfect.com.au/info_it_projects_fail...
blogs.techrepublic.com.com/tech-manager/?p=661

However I would add that code is not independent of the rest of the project! I have seen great teams reduced to producing bad code due to poor management and decisions. Bad architects (not producing code themselves so not part of the coding cycle) are also a killer. Of course poor requirements and coders also. Poor operational deployment or disaster. Poor sales and marketing strategy. Even poor customers as well. (heaven forbid we ever admit that!)
But that pretty much covers the entire field now...

Even if a project fails because of "bad code" it STILL does not mean that the code was the ultimate culprit. (5 whys anyone?) Some projects have already failed before a line of code is written due to unrealistic expectations/budget or the impending doom of the company.

Of course you could fallaciously argue that bad PM always leads to bad code and thus the theory is right etc etc. (Which the author appears to do in the last paragraph)

Not only would I argue (as others above have) that this is not always the case, I would add that your theory is now worthless and would demand an explanation of how such a shallow correlation is at all useful in actually solving the problem.

The author begins the article quite sensibly and makes a very valid point about the importance of code and maintainability etc but the conclusion is ridiculous. Possibly on purpose, but nonetheless ridiculous for it.

I would add a final point about some of the above posts inventing "perfect world" scenarios where developers are in a terrible company with slack requirements and somehow writing perfect code. Or other border cases to try and disprove this "theory".
What we should be interested in here is examples that commonly occur in the real world. Logic is not your friend here because as I said initially the coders are not independent of the rest of the project. We need to find trends, common problems and solutions for such. Inventing outliers is not going to help with that in the main.
In the example above what I have found personally is that bad requirements and bad PM lead to disheartened devs cutting corners and losing ownership of the project. Of course the best devs leave first leaving the rest to struggle on...etc etc. We all have seen it I am sure.

Re: I don't understand

I would add a final point about some of the above posts inventing "perfect world" scenarios where developers are in a terrible company with slack requirements and somehow writing perfect code. Or other border cases to try and disprove this "theory".

If you are talking about my posts, these are not inventions. What I am describing in my posts is the norm based on more than a decade of experience. You are far more likely to find a development team with good unit tests and regression tests than one with good requirements. Where I work now, we've spent at least as much (time and/or money) on unusable software as we have on working software. It's generally not because the software contains bugs but that it fails to meet the needs of the organization. This is for both custom and off-the-shelf software.

I have actually seen software that did not (and could not) work because it was so poorly written but it's the exception. Of course, in all of those cases, the requirements were not available so there was no way to fix it without going back to the beginning.

P.S. As a note of caution to those that you can just continually code and test and get to the correct solution without respect to time: I used to work for a company that had a $11 million contract with a government agency. They coded and tested and coded and tested and coded and tested etc. and then one day their key-cards didn't work. People lost their jobs. My employer was successfully sued by the agency for$350 million dollars and no longer exists as a independent entity.

Re: I don't understand by Mr Magoo

Question then: In the example you are talking about with great code and poor requirements did the project fail?
In the case of "unusable" software were people using it or was it a failure?
If not a failed scenario then things were not as bad as they could have been. I am talking about failed projects not struggling or imperfect ones.

I would like to hear more about the project you mentioned that did fail. Why? :)

None of this happens without people

You can read my original response to Uncle Bob here: www.docondev.com/2010/10/code-as-cause-of-proje...

As a craftsman, I am a strong proponent of excellent quality code along with good practices, strong relationships, and community. I agree that bad code is a common cause of project death. I also agree that poor requirements, poor management, misunderstood market opportunities, and many other factors can be direct or indirect causes to the failure of a software project.

My point was, and is, that behind all of these decisions and actions are people.

Re: I don't understand

Question then: In the example you are talking about with great code and poor requirements did the project fail?

Yes. That was the whole point. I believe I actually stated that right off the bat.

In the case of "unusable" software were people using it or was it a failure?

Are you seriously asking me whether people are using unusable software? If people were using it, it couldn't be unusable. The word 'unusable' means 'can't be used'. It's shelfware. Is that more clear?

I would like to hear more about the project you mentioned that did fail. Why? :)

The project failed to do what the agency needed to do within the timeline required. I wasn't personally involved with the project (it was a 10,000+ employee company) but I did know that the agency locked the development team out of the building while the team was still working. I don't know whether the requirements were good or not and I don't know the quality of the developers. The point is that one of the big problems with this industry is that we tend to lose focus on the point of the software.

Outside of your own team, no one cares whether your unit tests pass or whether you use stories or use cases. No one cares about your code coverage. What people care about is whether the software does what they need it do do and when they get it. All of this other stuff are just ideas about how we might accomplish that. No one cares whether your code is well written or not. The idea that requirements don't matter because the code is so clean is the height of self-delusion.

Re: I don't understand by Mr Magoo

Are you seriously asking me whether people are using unusable software?

If I had a dollar for every time someone said a system currently being used was "unusable" then I would be rich. So yes I am. Hyperbolic statements are very common don't you know. :)

The point is that one of the big problems with this industry is that we tend to lose focus on the point of the software.

I am in total agreement with this. In fact I don't disagree with almost all of your points. In fact I think I started by saying that there others have pointed out correctly that such cases exist! Case in point: your example was most likely a failure of project management (i.e. time lines and/or over promising to the customer) and this is very typical. In fact research states that this is the most common cause. (as I also said)

My original point was not that you were wrong but that when talking about solutions to the whole industry a single case (invented or otherwise) does not matter in of itself. What matters is what the (researched) common causes of failure are and then of course the range of possible solutions. Even one person's experience over a decade of experience is not really enough and mine is not either.

Its like the difference between the way you would correctly talk about social psychology and discussing your personal experience with patients. (For examples of mistakes with this, see Freud!)

So the correct way to debunk this argument is not to say I have a case (or cases) that does not fit your theory. Obviously when dealing with populations there are always outliers. It is to provide research that in fact the theory does not cover a significant amount of the population. (60, 70, 80%, etc)

The idea that requirements don't matter because the code is so clean is the height of self-delusion.

I totally agree. With the obvious caveat that terrible code usually leads to terrible software that does not meet user expectations. And as I said, code and its quality is not independent of the rest of the project! Terrible code may betray a terribly managed or designed project!

Re: I don't understand

The idea that requirements don't matter because the code is so clean is the height of self-delusion.

I totally agree. With the obvious caveat that terrible code usually leads to terrible software that does not meet user expectations. And as I said, code and its quality is not independent of the rest of the project! Terrible code may betray a terribly managed or designed project!

I think it's clear we are not in disagreement. I just want to clarify that I think having good requirements (how ever you may come by them) is the most important factor in project success. But I don't want to imply that it's the only important factor. You need good requirements and good people. Good coding is probably the second most important factor. Good project management is probably the third. I say probably because I hardly ever see good requirements so it's hard to say where things break down beyond that failure.

Saying you only need good requirements or only need good coding is no more sensible than saying you only need gasoline or only need tires to get a car going (obviously there are more things but humor me.) But if I could have only one, I'd pick requirements. When a capable development team is found, they can still be can used.

My anecdotes were also meant only to help illustrate the general principle. They are not proof in an of themselves.

One last note is that often coding teams are able to create something successful in the end even without clear requirements. The reason is that they are discovering the requirements as they go. In a nutshell, I think this industry needs to stop blaming coders for our high failure rate and start examining our management practices. My experience is that, on average, programmers are better than the results that are produced. This is a gross oversimplification but the upshot is: software projects fail because of poor management, not poor coding.

Missing The Point?

I think Uncle Bob's reasoning is that whatever goes wrong on a software project (requirements, usaubility, etc etc), it would present zero risk to the project/company if working code took zero time and zero money to create. If you build the wrong thing, no problem because it will take zero hours and zero dollars to fix it. You could have as many goes as you like. The more code costs to create (or change), the bigger the gamble on creating it or changing it. Therefore, the cost of code is what makes software development risky, and reducing the cost of code makes it less risky.

System that are configured also fail, altough the coding cost is 0.

Consider SAP implementations that have to configure lots of options
or complex operational projects like a directory service
or even data warehouses that do ETL,
all of those projects can fail without a single line of code written.
With projects, one part of the problem is the complexity of the technology.
The technology department (represented by the architect) may have no requirements, but that still leaves the other stakeholders, business and users (and sometimes different departments, governments, accountants, etc.) that can’t unite on requirements.
These are political issues that need to be resolved by the project leader. Consequently the project leader being the representative of the business, the business requirements are usually most important.
A project is doomed to fail if project management is not able to decide what is required of the project.
If the top messes up, the shit will roll downhill.
Close

#### by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

17 Discuss

Login to InfoQ to interact with what matters most to you.