My wife – a doctor – has been looking recently at safety systems in the aviation industry and their applications to the health service. In particular, how errors are reported and followed up. Apparently, NASA’s Aviation Safety Reporting System (ASRS) is the way to go. Every industry wanting to improve safety and reduce errors looks to NASA and ASRS.
Software is usually not quite as safety critical as aviation or health but one of the key targets for a software business is quality. Even if people would not die as a result of buggy software, we usually want high quality bug free software as the long term cost is lower and so profits are higher. Yet I often find the general attitude to bugs and mistakes is all wrong. The standard attitude is:
My boss wants bug-free software. Bugs make my boss unhappy. Therefore, my boss will be happier if he doesn’t know about the bugs.
It’s slightly simplistic perhaps, but who can honestly say that they’ve discovered some obscure bug in the system and felt absolutely happy about bringing it to the attention of management or other developers? Have you never considered just conveniently forgetting all about it?
This demonstrates a fundamental conflict of interest for developers. It’s far easier to develop code that your boss thinks is bug free than to create genuinely bug free code. Certainly in the short term. Your obscure bug may well be found a year or two down the line, but what’s the chance that you’ll be on the same project, or even with the same company by then? On the other hand, if you raise the bug and make it known to others, its probably you that will have to fix it. Probably today or in the next week or two. Developers don’t want that. Not when they’re being harassed for delivery dates, updated project estimates and so on.
It is almost certainly in the business’s interests that all bugs are known about. Even if the business decides that it is better if the bug is not fixed. The decision not to fix a particular bug may well be sound, but it’s a decision that should be managed. That is, management should take responsibility for the decision, it should be documented and interested parties should be consulted. Otherwise you end up with salesmen promising features to clients that are known not to work.
It everyone’s responsibility to record any known bugs to the bug tracking database. (You do have a bug tracking database, right?) Many people see it as the sole responsibility of the tester to record bugs in the database. That’s their job right? If anyone else added bugs to the database, they’d be treading on the testers toes. Worse, if you find a bug that the tester missed, doesn’t that suggest that the tester is no good?
There may well be good reasons why a tester would miss bugs that a developer would spot. I’ll discuss this further next time. There is a lot to be said on this subject and my next couple of posts will continue the theme. For now though, I just wanted to make the very fundamental points that it is everyone’s responsibility to record bugs and that it is never helpful to pretend that bugs are not there.
Be First to Comment