While listening to Perlcast’s interview with Pragmatic Andy Hunt, Andy said “Bugs tend to clump together.” I’ve said that many times myself — it seems to be true — but I never asked why.
I can think of two reasons immediately. First, complexity is one of the biggest enemies of effective software development. A complex section of code seems more likely to hide programming errors than a simple section of code.
Second, and perhaps more importantly, a piece of code for a poorly-understood customer requirement seems more likely to have bugs than a piece of code for a well-understood requirement.
Programmers have a decent sense of overcomplexity, at least if we can recognize that a piece of code is inelegant. Yet how do we develop our sense to find code that meets customer needs very poorly?
The smell of XY is a good one.
Doing what the customer tells you to because they tell you to, not what they need.
I've found that very often for whatever area the client works in, you need to become virtually a topic expert to really understand what's going on.
It's the same as in design work. Shortcuts, assumptions, quick and dirty results, it gets you into trouble. The best I can do is to be extremely self-critical with both my and the client's conclusion about what needs doing, and how I go about doing it.
And let me add that another good sign is that bugs love to clump around Open Problems.
Take a look at the bug counts for Mech (scrape the web), PAR (make binaries), Module::Build (install modules) and PPI (parse perl) :)
Maybe because changing code is bug-ridden--if it's an area of the code that has bugs, you're having to fix those bugs, ergo you're changing that part of the code, introducing new bugs?
Or maybe we just notice bugs when they clump together and don't when they are evenly spaced out? Especially now that it's widely claimed that they clump :).
(Not that I'm disputing the other explanations, just offering other ones that could contribute.)
Maybe it's just because a bad programmer worked on that particular piece of code.
Good points, everyone. I admittedly was exploring the idea that failing to meet customer expectations was at least as important as logic errors.