Source Code Crazy

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:

• Always use integrated source-code libraries and bug tracking. This is something that CMVC and other systems do excellently, and up till recently was fairly poorly served by the open-source software community, although projects such as Trac are doing a good job of closing this gap. The ability to see what changes are associated with what bug is invaluable. Anything else is a recipe for mistakes.

• Get rid of all the excuses. There are only two valid reasons for permanently closing a bug: (i) it’s fixed; (ii) the developer disagrees that the change will improve the software for the user. Anything else isn’t OK. A corollary of my rule about bugs and features being the same thing is that bugs can’t be returned just because they are feature requests. All bugs that aren’t targeted for a release currently being worked on are still open bugs (just with a different target field). All bugs we don’t want to fix because they don’t seem sensible to fix right now (which could be marked as such) are still open bugs. All bugs in an external dependency are still bugs (the whole system doesn’t work). All bugs that can’t be recreated were seen once (assuming you trust your testers) and are still bugs. A good bug tracker is a database, and will let you see any subset of these any time you want, so no-one needs to get blamed unfairly.

• Make sure each bug only has a few panic fields. ‘Severity’, ‘Importance’, ‘Priority’, ‘Ease of Recreation’, ‘Impact on Customer’, ‘Impact on Developer’, ‘Impact on Tester’ are all ambiguous. Pick a maximum of two, preferably just one, and make sure everyone knows exactly what they mean. After all, only one field really matters - how much does this affect the user of our software? Everything else should be secondary.

• What Joel says about explaining off-buttons to uncles applies equally to the design of procedures around software development - everyone will think their exception to the process is vital until you’re drowning in exceptions. This relates more to conventions surrounding software development rather than meta-software itself, but it’s still relevant. Keep it simple - regular builds on a schedule everyone knows; keep everything in one place; reduce the number of parties required to make a decision about any change to the bare minimum. Scott Berkun has a lot to say about this in his excellent book The Art of Project Management.

Fundamentally, though, maybe none of the above will help. Meta-software is perhaps destined to suffer from featuritis more than other software precisely because usability is not so important for its userbase (in my experience, most developers don’t like bad interfaces, but can also cope with them). Only time will tell if developers will be set free.