Sunday, October 17, 2010

The Cost of Code?

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.


  1. I agree with your statement, that code might be the underlying problem, but I also agree with Chad's statement that business is the underlying problem. One thing both of you don't consider is the fact, that business and code are intertwined. If the business side does not understand how code is developed, then there is a larger possibility that the project fails. On the other hand, if the "coders" don't understand how businesses work, the project is likely to fail either.

    That said we should try to understand the interconnectedness of the code and the business and start to understand that we live in a symbiotic system. That means that either side has to gain enough understanding of the other side in order to succeed on the project at hand.

  2. Wow) this is one of the best programmers essey I ever read!

  3. > If code cost nothing to produce, the cost of error [due to bad requirements and bad management] would be close to zero.

    Not exactly. 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.

    You make a good point, but I think a more defensible version of it would be that a software project is a delicate and complicated creature -- a lot of things can kill it, and a lot of things that *should* kill it (e.g. bad code) often don't.

  4. I agree with Markus, how many times have you been in a meeting where an idea was shot down because "that would be too hard to do". Customer dissatisfaction has a lot to do with bugs, missed deadlines have a lot to do with project failure.

    The cost of code directly effect what the business can and does do.

    However, if you want to be interesting, consider the question of how many big budget movies suck. Sometimes limited resources helps drive creativity. So how many projects fail because the code was too clean?

  5. These arguments always take the positions to the extreme and result in everyone being wrong, and I hope you noted the ironic use of "always".

    The artform we pursue requires us to know how to manage the balance between feature delivery and clean code.

    The cost of imperfect code will exist in the future in the same way that delayed delivery may incur a cost.

    The "craftsmanship" (not a bad word yet) that we employ enables us to strike the balances that best suite the situation we are in and pay the price when we choose.

    And, yes, we will be wrong sometimes.

  6. I am all for clean code and for learning to go fast. I believe that the best way to go fast is with clean code, not with dirty code.

    Your description of behavior at the limit does not ring true to me. Good ideas in the marketplace do not always drive out bad ones: take Smalltalk as one example. And good code produced instantly would enable a glut of bad products. If better ones took them out, then the bad ones failed. If, as is more likely, the good ones were unable to bring down the bad ones, then the good ones fail.

    Either way, in an infinite market of good code, some projects fail. In the end, cost is not, or should not be, the major factor in project success. The major factor should be value.

    That said, as a programmer, I can best help by providing code that does what is asked for as rapidly as possible. Clean code is important, and as a programmer that's the contribution I can make.

    But clean code isn't everything. One might wish it were, but it just ain't so.

  7. I agree with some comments here - the resulting code is an important piece but not the whole picture.

    In my opinion good code is necessary but not sufficient. (Of course, bad code could be sufficient in bringing a project down...)

    > "the single most effective way to increase the chances of project success?"

    I think improvements along two axes will increase chance of success the most: do more of the right things, and do the things more right. If you do one of them well but the other poorly, you'll risk project failure either way.

    If you improve both aspects a little bit, you improve chance of project success a little bit. If you just make the resulting code a little better, you might not increase chance of success noticeably.

    Good business process, picking the right product, but poor code - you'll incur the high cost of code errors mentioned in the article. Or, the resulting code is good, but is not selling for some reason - the cause is biz/ mgmt issues.

  8. GO Corp. was killed in several ways, and one of them was that they didn't stop coding long enough to fix their bugs and ship it. My source is Kaplan's "Startup: A Silicon Valley Adventure."

    I'm not sure Kaplan understood what was wrong with the software development system, but in hindsight my view is that they were undisciplined, didn't have a release plan, didn't have contact with actual users. Whenever someone would say let's release it, the head coder would write more code.

  9. The issue with this argument is that it assumes that the cost of code is huge. Huge is a relative word and it needs to be quantified to make the argument. To spend 100 million dollars for code might seem huge but what if you are Apple and that was the cost of creating OSX?

  10. @casron I think the argument here is that weighing the relative cost of software and judging it's importance on that basis is a mistake. The cost of software is both money and time, and almost every mistake made on the so called 'business side' will be duplicated in software side downstream. Hence if the cost of software was zero or close to it there's a significant benefit.

    However, as you attempt to reduce the cost of software you can get side effects which turn out to be equally or even more costly.

  11. If the cost of code would be negligible (or at least smaller) then the business would be allowed to fail faster, leading to a faster learning curve for the business and better business in the end.

    Therefore, indeed, the cost of code is an important factor for the business.

    I agree with the fact that the focus on cost alone (i.e. hourly rate) is a bad thing since it does not address the primary concern of fast failure. For that, one aspect is the craft of software development and another one is the human factor. Read for instance the classic 'Peopleware, productive projects and teams' for the effects that can have.

  12. I would think a company is more likely than a single project to fail because of bad code, since code quality is a long term advantage. When a project starts from scratch, coding is likely to be relatively fast even with low quality practices. But what if it starts with relatively ugly legacy code? If a company's management has some measure of realistic understanding of that fact, it might only initiate a project if it has a chance in spite of slow technical progress. On the long term though, if the company is unable to realize the projects it needs, it would be liable to lose in the end.

  13. For me Markus hit the point exactly: A software project usually consists of the business AND the coding side. Both have to be on an acceptable level that depends on the individual circumstances. If either side fails the projects fails. So Ingvald is right when he says: "(Of course, bad code could be sufficient in bringing a project down...)". Then the question is: Is it easier (or more frequent) that the business side does a bad job or hte coding side? - Or in other words: Where is the level of "sufficient quality" easier to achieve?

    Probably software does not have to be on a very high level to not be the reason for failure, but business does?

    After all: this discussion makes my brain flow!

  14. It should be important to all of us how(quality level) we do things. From that perspective, when project fail, it is very important who caused its failure. When everyone gave their best and best was really "the best of its breed", then who caused the failure is absolutely unimportant. Saying that some profession is causing more projects to fail then other, is same as saying there are less (real) professionals in that profession than in any other involved in project life cycle.

    So, I wouldn't dare to point finger to anyone (any side), but would rather follow the words (quote used in Mr Martin's previous blog entry) "Whatever you are, be a good one."

  15. No!

    I've watched too many companies implode because of people to believe that code has ever had anything to do with a project failing. Code is something people build to satisfy a business objective. The employees, technology, market and business to build are all chosen by people. Any business or project that fails is always because of poor choices people made. Code itself has nothing to do with it.

    Don't overstep code's effect on a business. Bad code will hurt a business, but won't guarantee it's failure. Conversely, superb code will make it easier for a business to succeed, but will not guarantee a succes.

    It's the people that make a difference... every time.

  16. One more thought: If a manufacturing company has a bad product quality, do you think it's because they don't know how to do it better? Maybe it is their business strategy (maybe unconsciously).

    So maybe bad code is a business problem.

  17. Logic failure. Code isn't the only expense for any company, even a web startup and web startups produce only a tiny fraction of all code ever written. 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.

    So, sorry, expensive code is only one possible source of failure.

  18. I think that regardless of whether code is all that matters or not, the fact remains that we, as developers have a responsibility to do what we can to increase the chances of the project to succeed. Since our end of the woods is the code, _that_ is where we should invest our efforts.
    As a developer, I would love nothing more than to be able to change how management does things, but I can't. I *CAN* make the code better, though.

    Therefore, craftsmanship matters.

  19. Well, if we're using analogies, how about painting a car part in a factory. If the part comes out the other end with a shoddy paint job, then surely it must be the fault of the person who applied the final coat! After all, you can't paint a car part without applying that final coat.

    ...except if the numbskull whose job it was to properly tape off the part did it wrong. Or the person whose job it was to scrub it with alcohol to avoid painting over specks of stuff. Or the person whose job it was to apply the primer. Or...

    Sure, it's true that code has a very important cost both in initial development and maintenance, but if someone didn't understand the problem or invented the wrong solution then the code's cost will magnify the bad effects. The insight of agile is to expect and optimize a lot of turnaround between phases.

  20. I agree with everything except the statement: "Unfortunately (the offshoring) strategy (to reduce coding costs) didn't work as well had been hoped."

    What do you mean "unfortunately"? That's like saying, "Unfortunately, in the march to Moscow Hitler's army bogged down and could not maintain its supply lines." It is extremely _fortunate_ that the outsourcing strategy didn't work as well as had been hoped.

    Whose side are you on?

  21. Who cares if the code is right if it is just not the right code?
    Good code has intent, not just internal quality; otherwise, it is just develop by numbers ...
    Customer and client interaction are key to discovering the right thing to do.

    Doing the thing right is just knowing your tools and caring about them. But project success involves attacking the right problems.

    We have had too many people that do not know what are the problems to solve or even if they can be solved just with sw ...

  22. As far as i have seen in my career, most projects that I personally have seen failed are due to a lack of well defined business requirements. This lack of business requirements turns into additional costings which in turn don't support the actual benefits gained from the enhancement / project.

    When dealing with users from a business, there is always a "gap" between what can be accomplished easy and what may be a major design impact. It usually depend on a couple of items.

    1. What is your target framework
    2. What is your infrastructure
    3. What is the quality of your architects

    and most importantly

    4. What are are the costs (initial and ongoing) regarding the project

    Most projects that i personally have seen fail are regarding item 3 but a decent framework will always lessen this impact. On another note, if expectations are not met, there will always be negative feedback (usually due to unforeeseen circumstances - like environment issues) however the only instances i have seen projects fail is due to a lack of business specifications.

    Most of my experiences however have been with high level corporations / government areas, so i cannot comment on the smaller business scenario however with the price of development increasing (with the exception of oursourced companies), there is always a demand for a lower cost fully functional system that meets the need of the "business sponsors" (wherein lies an obvious inherited issue).