This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: The Biggest Misconception in Software Development
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
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.
Previous Topic
