Agile Zone is brought to you in partnership with:

Michael Norton (doc) is Director of Engineering for Groupon in Chicago, IL. Michael's experience covers a wide range of development topics. Michael declares expertise in no single language or methodology and is immediately suspicious of anyone who declares such expertise. Michael is a DZone MVB and is not an employee of DZone and has posted 41 posts at DZone. You can read more from them at their website. View Full User Profile

Code as a Cause of Project Failure

11.10.2010
| 2324 views |
  • submit to reddit

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 GunsA 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 MenOur 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.
References
Published at DZone with permission of Michael Norton, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Greg Helton replied on Thu, 2010/11/11 - 12:14am

Bad projects succeed all the time.  New RPG programs go into production every day.  Have you seen RPG, that stuff they write on the IBM iSeries & AS400?  RPG programmers like their monolithic programs and their flat, non-relational databases.  Code matters but seldom has any impact on management and management are the people who decide if a project succeeds or fails.

See point #2 in this list: http://agile.dzone.com/news/nine-transformative-aspects 

Many software developers are proficient in the software process even though they write bad code. Their code will have many examples of each of the seven wastes of software development.

    * Partially Done Work
    * Extra Features
    * Relearning
    * Handoffs
    * Delays
    * Task Switching
    * Defects

These wastes, although real, fall into the category of soft dollars and nobody is accounting for soft dollars.  No matter how much anyone cries about bad code and shouts warnings about costs, they are all Casandras.  I think the solution has to be more than telling readers that they should write better code. The only thing that will change our profession is the application of metrics which transform soft dollar qualitative judgements into hard dollar quantitative facts.

Michael Norton replied on Thu, 2010/11/18 - 2:42pm

As I stated, "I don't agree that all failed projects are due to code". My point is simply this - you cannot attribute the failure of a project to code for it is the delivery team that makes the decisions that result in failure. The code is not accountable, we are. Truthfully, it is the process that fails, but that is another debate entirely.

Emma Watson replied on Fri, 2012/03/30 - 3:55am

And how do we pull the trigger? By producing the bad codes. I'm recently working on re-engineering a failed project. The business idea of this project was and is still very good, but it was mostly code failure. Spaghetti codes make the maintaining cost unbearable.

JDBC

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.