Show all posts
6 years ago

Do Really All Projects Fail Because of Code?

Today I've read two interesting posts: The Cost of Code by @unclebobmartin and Code as a Cause of Project Failure by @DocOnDev. They discuss various arguments to prove that all projects fail because of code. The main argument is that if code is free and light-fast to change, project can't fail. OK. But this case is rather extreme and obviously impossible. We don't live in a world with hyper-space jumps, teleportation and free medicine (unfortunately). In real life code costs a lot and it will be true in the next decades for sure, so this argumentation proves nothing. In ideal world there is no such thing as code. In ideal world you have a solution in seconds without computers, software and other complicated things. So I don't buy this idea. Code is not the main reason for projects failure in reality.

Code is not free. Code is expensive. We do not sell source code though, we sell solutions. If it is possible to create a solution without source code, it would be fantastic. Let's take an industry that handles tangible objects. Automobile industry does not sell carbon and metall โ€” it sells cars. It sells a solution to transportation problem. Teleportation is an ideal solution, but we can't teleport nothing but electrons, sadly. We buy cars to get from point A to point B. We buy a solution.

Code != Solution

I think the main problem with projects is that they provide either bad solution or no solution at all. Nobody buys stagecoaches these days, since there are more efficient solutions. If a project does not solve anything, it will fail. If a project solves something, but ย in a nasty, unusable way, it will fail. 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.

You may argue that with clean code you can refactor it fast and change everything. C'mon, it will be a full re-write if it solves the wrong problem. Can you fix a stagecoach to make it a true competitor of a car?

solution

On the other hand, if a projects solves a right problem, but with some issues, clean code is very important. You can't adopt fast without it. You can't change things and react to people demands.

Don't get me wrong, I believe that clean code is an important thing, but it is not the most important asset in software development.

  • http://profiles.yahoo.com/u/QHTRDS6KOB7USFXPE4N3WXMOYM Olga

    No wonder that those 2 highly respected gentlemen put it all down to the cleanness of code. They're software craftsmen. Not businessmen or entrepreneurs, although they're aware of business reasons for projects success/failures to some extent. So they look at the reasons for failure within their area of responsibility – which is code. But code is really like a car. A tool to go somewhere and to create something. If you write a perfect code but for the inappropriate or wrong solution to somebody's business or whatever problems – the project fails, notwithstanding the shiny code.

  • http://twitter.com/DocOnDev Michael Norton

    I think Bob overstates the importance of code. As I state in my post, “I don't agree that all failed projects are due to code[…]”

    My point is that people are the root cause of project failure. The creation of solutions is a uniquely human endeavor. 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.

    So, you and I agree as much as Bob and I agree. Not all projects fail because of bad code and writing code poorly is unprofessional, unless of course, you are not a professional code writer.

  • http://palazkov.blogspot.com/ Valentine

    you said:

    ' If you write a perfect code but for the inappropriate or wrong solution to somebody's business or whatever problems – the project fails, notwithstanding the shiny code.'

    Codebase serves two main purposes:

    – to fulfil business requirements
    – to be readable and flexibly enough for further changes (via refactoring)

    We can't miss any of two points from above. Thus, we can't afford code which fulfils requirements without cleanies, and vise-versa.

  • https://www.targetprocess.com/blog Michael Dubakov

    Michael, thank you for the clarification. It seems we formed a nice triangle that covers all rasons of projects' failures ๐Ÿ˜‰

  • http://blog.brodzinski.com/ Pawel Brodzinski

    “On the other hand, if a projects solves a right problem, but with some issues, clean code is very important.”

    It basically means clean code is very important in more than 99% of cases. Show me projects which solve right problems with no issues whatsoever.

    If we see a success or failure there are always many factors which stack up to the result. Majority of projects fails for both business and technical reasons. Projects are poorly defined business-wise and then quality is low and this combo brings you to the dead end.

    Of course a single reason may bring you to a failure as well, but you have to screw it up hard way. I mean refactoring stagecoach into BMW is as probable as finding PC genie which shows you how to produce code at no cost. So at this point you're both equally wrong… which also means you're both equally right.

  • http://twitter.com/isaac_abraham Isaac Abraham

    Hmmm, not sure about the “more than 99% of cases”. In my experience, projects more often go wrong when the solution tries to solve the wrong problem rather than the implementation of that solution.
    Yes, I've seen projects go wrong because of technical implementation details – but more often than not, the problems occur far earlier in the lifecycle of the project.

  • https://www.targetprocess.com/blog Michael Dubakov

    “It basically means clean code is very important in more than 99% of cases”

    No, it is not :) Very often project solves a wrong problem. Or solve a right problem, but solution itself is just terrible, so refactoring can't be applied.

    Isaac is right.

  • http://blog.brodzinski.com/ Pawel Brodzinski

    The point where I don't agree with you guys is definition of “solving the wrong problem.” Again, if we want to make a competition to BMW out of stagecoach by refactoring we are in such small margin it isn't even worth discussing.

    Typical situation with solving wrong problem is solving slightly wrong problem. And this can be covered with redoing small parts of the projects and not the whole code base. After all people aren't that dumb.

    Then of course we can address wrong business decisions as the sole reason of failure but it just isn't fair. Most of businesses start with little knowledge and they learn along the way, which means products are changing. As Seth Godin once stated on businesses: “what you start with is wrong.”

    Is it still solving the wrong problem?

  • https://www.targetprocess.com/blog Michael Dubakov

    Your arguments are true. But there are 3 ways to fail with solution:

    1. You solve wrong problem (I agree it is relatively rare case)
    2. You solve right problem, but solution is 80% bad (I mean functional solution, I don't mean code)
    3. You solve right problem, but solution is 20-30% bad

    What can we do in all these cases.

    1. Learn from mistake and abandon the project
    2. Learn from mistake and re-write from scratch
    3. Refactor

    I believe refactoring can be applied to the third case only, when you have a solution that is not perfect. For 2 other cases code quality does not matter.

  • http://blog.brodzinski.com/ Pawel Brodzinski

    Almost agree. There are solutions which are x% bad, where x is between 0 and 100.

    Now the only thing is to decide how frequently we see those which fall into groups 2 and 3. My wild-ass guess we both go here with our gut feelings so the case is unresolvable although consensus has actually been reached :)

  • https://www.targetprocess.com/blog Michael Dubakov

    Nice! Let's shake hands then :)

  • synfluent

    Good code will never overcome poor architecture.

  • http://xpinjection.com Mikalai Alimenkou

    Code is just an instrument to archive business goals of the customer. It is hard to do something good with broken and dirty instrument, but still possible. Having wrong goals makes it impossible. With clean and high quality code you have more time to concentrate on business goals.

  • http://www.ngpanwei.com panwei

    Beauty is in the eyes of the beholder. Failure is also in the eyes of the beholder.
    Ask a code expert why project fails, he will say code. Because when a development team seeks his/her help, the team have in most cases come to realization that they have a code problem. So, ask a code expert what is **the** solution to project failure, the answer is good code.

    In general:

    Ask a <xxx> expert why project fails, he wil say <xxx>. Because when a team seeks his/her help, the team have in most cases come to realization that they have a <xxx> problem. So, ask a <xxx> expert what is **the** solution to project failure, the answer is good <xxx>. By the way, <xxx> is the way the <xxx> expert makes a living.

    </xxx></xxx></xxx></xxx></xxx></xxx></xxx>

Get started for free

Sync up your teams with a visual project management tool that adapts to your organization and gives you transparency across different projects and departments. Visualize every step of the way.

Get started