Software Change Management Should Change

2006-07-24

Almost all software, whether it be public domain, open-source, or commercial, is not just released once. Typically it goes through many versions, changing (and hopefully improving) each time, sometimes adding features, sometimes removing bugs or problems, sometimes introducing new ones. This change is normally managed (at least for larger software systems) using two or three elements:

Version control systems (also called source control or library systems). These are typically used to keep track of different versions of source-code, enabling previous versions to be retrieved, different parts of the software to be merged together, and so on. CVS is a well-known open source example.
Bug tracking systems (bugs are sometimes called defects). These are used to keep a list of all the outstanding bugs and details about them. Bugzilla is a well-known open-source example.
Feature or requirement tracking systems. These are used to track new features that need to be added to the software (wherever they may come from).

In some cases, these systems may be integrated, in other cases not (integrated systems are normally more useful: for example, you can easily ask the question: ‘when this bug was fixed, what code changed?’).

Currently, commercial software companies often follow something akin to a waterfall model and treat features as long-term work items and bugs as short-term (as an aside, the original inventor of the waterfall model didn’t believe in its effectiveness). This is a risky game to play if your competitor can implement new features before your model allows you to. It’s likely that as commercial software becomes under increasing pressure from open-source competitors, often using nimble development methods such as agile programming, commerical software production companies will need to turn around production of new versions with new features faster than before to survive.

One of the mismatches occurs in treating bugs and features independently. Bugs take time to fix. Features take time to implement. In a sense, both are actually customer requirements, even if the customer hasn’t asked for them. Bugs customers won’t notice shouldn’t be fixed, and bugs they will notice will become a requirement even if they haven’t noticed them yet. Features either the customer has asked for or you think they may want should be implemented. Features that only you want are a waste of time. Bugs that your customer thinks are bugs normally are, even if you want to call them a feature.

So this leads to my conclusion (and not everyone agrees): bugs and features are actually the same type of thing. They are both customer requirements and should be managed the same way, triaged the same way, and developer time assigned to them in the same way.

Many open-source projects already treat features and bugs like this. Firefox’s Bugzilla, for example (in common with most Bugzilla installations), tracks features with a severity of ’enhancement’. This probably isn’t ideal; features shouldn’t be treated as second-class citizens compared to bugs. But it’s a step in the right direction. This way, developers of Firefox see bugs and features as being of the same kin; lack of features cause some customers just as much pain as lack of bugfixes.

This issue is far from settled, and there are strong opinions out there that disagree with me. But it is clear that everyone involved in software development should be aware that this is not a solved problem.

Comments

[...] I’ve thought for a while that build, source-code management, and bug tracking software (which I’m collectively calling meta-software) could, and should, be so much simpler. I’ve written previously about my contention that bugs and features are the same thing, but the problem is wider. Software has a tendency to acquire features over time, and software that’s used to make other software is no exception. Here are some assorted thoughts about how to improve the situation: [...]

— Andrew Ferrier’s Blog » Blog Archive » Source Code Crazy 2006-12-12 21:38

You may be on to something here, since we've been finding out the same in our project at <a href="http://lemill.org/trac/report/3" rel="nofollow">http://lemill.org</a> where we do keep defects and enhancements in a single list, but separated. We've noticed that the line between defects and enhancements is a fuzzy one - of course, a defect reported by a developer most likely is quite technical in nature, but when the customer reports a bug, it's usually more in the lines of "this needs to work differently", and while sometimes it can be managed with a simple correction, other times whole layers of new functionality are needed, and effectively the defect is a huge enhancement. We haven't yet solved this issue of how this should be handled.

— Tarmo Toikkanen 2006-11-17 11:51

Hmm, that's an interesting thought. However, I *can* think of bugs where there hasn't been agreement on how they should work either :) Fundamentally, I agree with you - there is a continuum - just because I'm advocating treatings bugs and features as the same type of entity doesn't mean we can't have some being 'problems' and some being 'new function'. To me, the most important thing is they should go through the same processes: kept in the same list, being reviewed and triaged together, their priorities mixed together, etc. Developers, when stuck for something to do, should always be able to go to this list and implement the highest-priority item on it, whether that be something new or fixing an existing problem.

— andrewferrier 2006-07-27 08:03

By far the biggest difference between bugs/defects and customer "requirements" is that with few exceptions, everyone can agree that a defect is something which *should* work differently [whether it will be made to work that way depends on its severity etc] whereas requirements gather from customers are often of the nature "customer Y would like to have X" which says nothing of what customer Z would like in that area and may needs careful management, analysis and prioritisation before it becomes clear that it must be fixed. Of course, the real world is fuzzy and there is really a continuum here - I can think of many occassions where there was a bone fide bug that customer Y wanted fixed whereas customer Z absolutely did not want it fixed since it wasn't impacting them (perhaps they had already worked around it, or do not exercise that functionality) and any potential fix could of course introduce further defects which customer Z wanted to avoid...

— dps 2006-07-26 22:45