Comments on: Software Change Management Should Change

By: Andrew Ferrier’s Blog » Blog Archive » Source Code Crazy

Andrew Ferrier’s Blog » Blog Archive » Source Code Crazy — Tue, 12 Dec 2006 21:38:37 +0000

[...] 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: [...]

By: Tarmo Toikkanen

Tarmo Toikkanen — Fri, 17 Nov 2006 11:51:41 +0000

You may be on to something here, since we’ve been finding out the same in our project at http://lemill.org 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.

By: andrewferrier

andrewferrier — Thu, 27 Jul 2006 08:03:34 +0000

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.

By: dps

dps — Wed, 26 Jul 2006 22:45:26 +0000

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…