Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Sunday, June 04, 2006

The Biggest Misconception in Software Development

Software development is a tricky profession. It seems like every year a new methodology is born, a new technology rises, and the industry annoints a new hero.

C++, then Java, then C#, now Ruby.

Procedural progamming, OOP, Component-based development, and now SOA, whatever that means.

Waterfall process, then iterative development and RAD, then Rational Unified Process, and now Extreme Programming, Scrum, and agile methods.

But one thing that hasn't changed much is the idea that software should be bug-free. Zero defects. Elegant perfection.

Sure, we all understand that perfection is just an ideal, but we still should strive to fix every bug that we know about, right?

Well, it's this idea that is the biggest misconception in the software industry. Not all bugs should be blindly fixed without considering the consequences.

Consider an example.

You create a simple web store that can display products, add them to a shopping cart, and accept payment. After it goes live, you discover a bug in the product catalog than prevents products with hi-resolution images from displaying properly.

Now, only 2 products out of my 100 have hi-res images, and these aren't very popular products anyway.

You can do one of two things:

1. Ignore the bug for now as a low priority item, and focus on adding new features to the store to boost sales.

2. Work on the bug, make sure nothing else breaks, and redeploy the store.

If there are important new features that your customers are clamoring for (or that will prevent you from going out of business next month), you need to carfeully prioritize this work.

Unfortunately, it's not as if fixing this bug can be done in isolation. What if the fix introduces another, more serious problem? Is the risk of adding more serious bugs worth the benefit of fixing this one? Is the effort spent on this issue better applied to another more pressing feature?

Your approach then, has to take into account both risk, frequency, and severity. How many people are affected and how likely are they to encounter the problem, and how severe are the effects of encountering it? If you decide to fix it, how likely are you to introduce another problem inadvertently?

In the scenario above, very few customers will see the problem, as it only affect 2 unpopular products. Perhaps the fix will be in a delicate area of the code, and may cause the rest of the products to be incorrectly displayed. That would constitute a high-risk fix, with low frequency, and a low severity. Probably not worth doing right now.

On the other hand, a bug in the pricing engine that gives customers a 70% discount on all purchases would be much more severe, and could demand immediate attention. Pretty clear value proposition for that one.

Now, I'm not saying that as software professionals, we shouldn't strive to write clean, well-tested, error-free code. In fact, there are many approaches that are becoming popular, such as Test-Driven Development, Continuous Integration, and even Pair-Progamming that can help developers keep their code performing well.

But the reality is that as long as there is software, there will be defects. As part of a responsible product development effort, those defects should be prioritized along with the features, and the decision to work on them should be well-reasoned.

I've worked with many developers (and testers) that think this is just wrong, and that it's unprofessional to leave any known bugs in your software. But like anything else in life, it's all about tradeoffs. Obviously if all of the known bugs are trivial, low-risk changes, it's reasonable to fix them. But obsessive bug-fixing can actually cause more problems than it solves.

So fix your bugs, but make a conscious decision about them. If the benefits aren't there, you may be better served leaving a few until later. You might be avoiding even worse ones by doing so.

For more on agile tools and techniques:
(Tags: , ,

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • Nice posting, Dave. You should post this one over at, a digg-like site specifically for developers,

    By Blogger Rick Ross, at 7:52 AM  

  • Your article looks like another case for "Good Enough Software"

    I know that this approach sometimes makes sense but you should not call 'bug free' software a misconception.
    Read, for example, what Pete McBreen says about it :

    By Anonymous Anonymous, at 9:27 AM  

  • oaz,

    Thanks for the feedback.

    The point I'm making is not that trying to create bug-free software is wrong.

    The point is that bug fixing has a cost, and it has a risk.

    The misconception is that bugs don't need to be prioritized just like any other feature.

    With careful prioritization, each business can decide how to handle their backlog, with their customers in mind, not just an abstract notion of quality.

    By Blogger David Churchville, at 10:05 AM  

  • >> The point is that bug fixing has a cost, and it has a risk.

    Sure, but it doesn't mean much.

    1. first about the risks : when you have more than one bug in the app, they tend to combinate and it is quickly much harder to debug and more critical to do so.
    2. people who doesn't know how to fix properly a bug a less likely to write anything of value beyond the difficulty of the bug.

    that why coding methodologies (design by contract anyone) are so important.

    by the way, you article is from an economic point of view, forgetting the difficulty to debug N bug is exponential, while the resources are linear.

    By Blogger Wagnerius, at 12:51 AM  

  • Yes, fixing bugs is risky because writing code is always risky. This is why you should have good regression tests.

    By Anonymous Anonymous, at 7:56 AM  

  • This argument is a straw man. No one who actually ships software believes that every bug can be fixed. When deciding to fix a bug, especially near the ship date, the harm caused by the bug, the risk of the changes required to fix the bug, the number of users likely to be affected, and the amount of test time available all feed into whether the bug will be fixed immediately or postponed.

    By Anonymous Anonymous, at 4:36 PM  

  • re: "This argument is a straw man".

    To clarify, my argument is not that everyone thinks all bugs should be fixed.

    It's the more subtle idea that bugs are different than features, and so should be separately evaluated when doing product planning.

    Bugs are often invisible at the management level, and thought to be something that should just be fixed, as in - Aren't we paying you programmers enough to get it right the first time?

    So the real issue is that if we accept that software will have bugs, then we should embrace them in the planning process, and not let bugs get fixed without oversight.

    By Blogger David Churchville, at 4:45 PM  

Post a Comment

<< Home