Rant on.
In software terms quality does not mean walnut dashboards, it does not mean gold plating, it does not mean polishing to perfection. These things may happen in a development team but they should not.
However you define quality for a piece of software I bet it has no place for “bugs.” In fact, I bet anyone who has actually written a definition of “what is software quality” included something like “Few or no bugs.”
What ever else “software quality” means it does mean producing largely bug-free code. The best performing teams can deliver on this. They may not be entirely bug free but they can be largely bug free.
When bugs are present, when quality is compromised, bugs appear. Customers are unhappy – they may loose money or terminate contracts. Or they may keep calling your support desk.
Bugs destroy predictability because they can appear at anytime and demand fixing.
Bugs destroy productivity because they disrupt work and take time to fix for little apparent gain.
Bugs destroy any hope of meeting schedules because nobody knows when the bug finding and fixing will be done.
Bugs and poor code quality hinder future work because developers find themselves battling past problems.
Compare this with developers who always work on new code, those who start with a new sheet each time, those who carry none of yesterday’s baggage. Developers who work on fresh prototypes will always look better than those who work on a legacy.
Bugs make it difficult, if not impossible, to have a rational conversation about “what to build next” because there are bugs to fix. Bugs discussions don’t add value because bugs don’t add value. The only value fixing a bug adds is putting value back that was missing in the first place.
Bugs make it difficult – no, impossible! – to have a rational conversation about delivery dates too because nobody believes the dates will be met.
And when you have lots of bugs developer, testers, requirements engineers and, most of all, managers, forget how to do their real jobs because so much of their time is taken up with bug conversations.
Yet techniques for combatting bugs do exist and are used by the best companies.
Code reviews are one of the most powerful techniques for removing bugs but when used in a low trust environment with confrontation they can descend into school yard bullying.
Test Driven Development (TDD) is an extremely powerful technique, one team at Microsoft recorded a 91% reduction in bugs. While many developers are now aware of TDD few actually practice it, and many of those who do practices it erratically or without real understanding.
To embed TDD in the culture required support: specifically technical coaching. This approach also helps address hidden skills deficiencies, e.g. poor use of object-oriented techniques. Technical coaching is expensive simply because it is one-on-one with developers.
Look, I happen to think TDD – and by extension cousin BDD – work. I know not everyone agrees with this, that is your right. I just ask: if you don’t believe TDD will help, what do you suggest? – just add your suggestion in the comments below.
A third technique is pair programming, while controversial and instinctively disliked by many programmers but can be highly productive.
These are not the only techniques. There are other, often complementary, techniques available – see my old “Things to do to improve code quality” blog.
I hate bugs but there is something I hate more than bugs: the attitude that tolerates bugs as “a fact of life, something that will always be, something we can’t do anything about.”
I don’t hate people who think they can create software quicker by tolerating bugs. I don’t hate them because they aren’t worth hating. They shouldn’t be in the industry. Quality software, few bugs, makes for shorter delivery cycles, lower costs and happier customers.
The attitude “Low quality is faster and cheaper” has no place in our industry. Anyone who believes this doesn’t deserve to work in the software industry.
One of the big problems I see with the software industry is that so many people have stopped aspiring to do anything better. The philosopher Aristotle is reported to have said: “Our problem is not that we aim to high and miss, but that we aim too low and hit”.
Most of all I hate the attitude that aims low with bugs and code quality.
Rant off.
(If you want a longer, more rational, discussion on how to deal with bugs have a look at the draft “Bug Management Strategies” chapter (PDF) for Xanpan book 2 which is available from my website. See also the appendix in Xanpan book 1.)
| Reference: | I hate bugs (A rant) from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
