Genii Weblog
Why bugs don't get fixed
Sun 23 Apr 2006, 08:29 PM
Tweetby Ben Langhinrichs
I have decided that expecting myself to actually post Show 'N Tell Thursday posts on Thursdays could lead to my not fixing bugs in a timely manner (see #10 below when you get to it), and so have decided to ignore the day of the week and simply post when and how I like, but I'll still use the graphic because it looks cool and isn't animated or noisy and doesn't spread kitty litter all over the place.Oh yes, and I may update this post a few times to try to make it a bit more coherent. If you don't like bloggers who edit their posts, you may want to avert your eyes for a few days and come back then.
Why bugs don't get fixed
It is a common question asked on the various forums I read, "Why hasn't [fill in the blank] bug gotten fixed, even though it has been around forever?" and since the forums are Lotus Notes forums, the questions tend to be about Lotus Notes bugs. The funny thing is, if you hang around on Exchange forums, you hear the same questions, and the same with Oracle forums and pretty much anywhere else, including open source forums where the obvious answer is "because you didn't get off your lazy bum and fix it".
But in most of these cases, the software is not open source, and the lazy bums are perceived to belong to IBM... or Microsoft... or [name of software company]. But despite the frequency of the questions, many people seem genuinely mystified about why these bugs don't get fixed. I am not expert, but I am in charge of fixing bugs myself (as well as responsible for inserting them, I'm afraid), so I thought I'd tackle the question head on and at least provide some perspective.
First though, I should dispel a couple of myths.
Myth 1) If you want a bug fixed, you should provide a business rationale.
While this may be true on rare occasions, it is often simply a delaying tactic. If you want a new feature, a business rationale may be warranted, and even helpful, but presumably the features that are broken have already been justified. Besides, very few people say "I'd buy Software X if that one bug were fixed". Some people may stop using the software due to a specific bug, but even that is relatively rare (for a clear example, see Windows).
Myth 2) Once a bug is reported, it will be fixed as soon as the software company gets finished with the bugs reported prior to that - the FIFO theory.
This is manifestly untrue. All software has bugs, and the more complex and important the software, the more bugs it will have. Those who use Lotus Notes may not want to hear it, but it is true. Therefore, software bug resolution is almost always a triage system. "What is the most important bug in my area?" may be asked, but little consideration is given to "Which bug was reported first?" This is actually a good thing, because otherwise the software developers would be busy fixing bugs that might effect just one or two users, or even chasing phantom bugs, while really important show stopper bugs were being ignored. This is the same reason emergency rooms don't operate on a FIFO system, which may irritate you when you are waiting four hours for a broken leg to be set, but may relieve you greatly when you go in with a heart attack.
So, having put the myths aside, why don't bugs get fixed? I have listed a few reasons in no particular order.
1) Bugs don't exist in isolation. They exist only when they effect someone and are reported.
This is important to remember. A bug may be found in software that has been around for years, but that does not mean the bug has existed in the software for years. It means that a weakness has opened up. If this seems untrue, consider a software package that works well for all its users. All of a sudden, another software package starts conflicting with the first, but not in a way that can be blamed on the second piece of software. The software that has been working so well starts to crash. It shouldn't crash, and it even has a clear bug, but it wasn't a bug until the second software package came along.
Even more common is the bug that is not reported. Like the tree that falls in a forest when nobody is around, the bug that is not reported won't be fixed. For the software developers, it simply doesn't exist. Of course, they might run into the bug themselves and report it, but until then it doesn't exist. If there is a bug that has been bothering you for years, but which you have never reported, consider the possibility that nobody else has either. It may be hard to believe, but I have watched major bugs reported to IBM months or even years after they were first noticed. Once they were reported, they were fixed. And no, reporting it to your mates down at the pub doesn't really count, unless you habitually share a pub with the software developers themselves.
2) A bug may seem easy to fix, but the bottom card of a house of cards may be easy to place but hard to remove.
It is not uncommon to see a bug that should be easy, easy , easy to fix, if only you could spend ten minutes with the source code. What may be hard to see is that the bug may be in some very fragile code with comments that say "Don't touch on pain of extreme death" and with the original developers now working somewhere else. It may be that the fix looks incredibly simple and tempting, but better judgement says "Fixing that will break a dozen other things, but I don't know which dozen other things."
3) The bug may not be in software that is "owned" by anybody.
This is one that many people outside the software industry may not quite understand, but it is critical. Software developers have their areas of interest, their areas of expertise, and their areas of responsibility. (Sadly, these may not always coincide, but that is a matter for a separate post) Just as a carpenter won't want to fix your electrical problem, and a plumber may not want to paint your walls, a bug may not have a person assigned to fix it. There are a number of areas on Lotus Notes that have fallen victim to this over time, including the rich text classes, MIME rendering, the formula language, etc. When somebody is assigned, they may go after and fix a bunch of long standing bugs in that area, but you don't have much control over when that might happen.
4) It matter who reports the bug.
Somehow, bugs that get reported by General Motors seem to have a bit more weight than those reported by Mike Micro-ISV. I think most people understand this one.
5) It matters to whom the bug is reported.
This is a bit less obvious. Sadly, going through appropriate channels doesn't always work. I have had bugs that have bothered me immensely reported (not by me because I didn't have authorization) to IBM support to no avail, but when I have found the right person at Lotusphere and showed the problems directly, they magically got fixed in the next release. This does not mean the bugs shouldn't get reported through the proper channels (see #1). It doesn't even mean that you can get hold of the right person. It just explains why some bugs get fixed rapidly, just based on who hears about them. A classic case came recently in the Business Partner forum, where a developer who participates said:
I re-opened [SPR X] ...and assigned it to myself to fix it (not that I need more work than I already have, but I want to see this fixed myself, so I'm just gonna do it ;-)
6) The bug may not be reproducible.
This is critically important, so I put it right in the middle. If the developer can't reliably reproduce the problem, it becomes very, very hard to fix. If it can't be reproduced at all, it almost certainly won't be fixed, no matter how earnestly you insist that it is a problem. The problem may be specific to your machine, it may be specific to your odd combination of software and hardware, or it may be user error, hard as that may be to believe. No matter what the issue, if it can't be reproduced by the developer, it usually won't get fixed.
7) The bug may have been fixed already.
I know it sounds incredible, but a number of times I have had people complain about a bug that has been fixed already, but they have not, or cannot, upgrade to take advantage of the fix. While it is frustrating for them, it is even more so for the developers who have to hear the complaints even though they have actually fixed the bug.
8) The bug may not be considered a bug.
Sometimes, you think it should operate one way, and the developer thinks it should operate another, and there is no independent judge to back you up. Unless you work for General Motors (see #4), the "bug" may remain.
9) The bug may not matter to anybody else.
This is related a bit to #4 and #5, but it is a frequent reason why bugs don't get fixed. Yup, nobody cares. I can relate to this one directly with two related problems that bother me greatly. At Heinen's Supermarkets, where I shop regularly, the register receipt spells "Cheerios" incorrectly as "Cherrios". It has done this for the past TEN YEARS, even though I have complained occasionally (because of #1). It seems unlikely that this would be related to #2. It could possibly be related to #3. I am a frequent shopper, so it is unlikely an issue of #4, but perhaps I flatter myself. Similarly, the BP gas station near our house happens to have a carwash, and an incredibly irritating message that flashes over and over saying "Cawash code good for thirty days". There is plenty of room for the word "Carwash", but it was mistyped a number of years ago. Again, I have complained to no avail.
The problem, I have decided, is that nobody else is bored or picky enough to care. They know they bought Cheerios, not Cherrios. They know they paid for a Carwash and not a Cawash, so they simply don't care. And because nobody really cares, I will probably be fuming about these two bugs for the next decade.
And finally...
10) The developer may be busy updating his or her blog and simply not feel like fixing have time to fix your bug.
Lest that be me, I will go now and work on a few long standing bugs. Sigh!
Technorati Tags: Show-n-Tell Thursday, Lotus Notes, SnTT
Copyright © 2006 Genii Software Ltd.
What has been said:
453.1. Jerry Glover (04/25/2006 07:28 AM)
Speaking of broken, I guess the basic BBcode formating doesn't actually work here for comment links (it's dominoblog?).
453.2. Ben Langhinrichs (04/25/2006 07:36 AM)
Actually, it is a great self-referential point. The BBcode formatting works fine, but is intentionally delayed (look now and you will see the link working) as a way to prevent a different issue, comment spam).
By the way, I agree that if it appears to be a bug to the user, it could easily be considered a bug, but for the purpose of this post, I am not saying what should be done. Instead, I am explaining why some bugs don't get fixed. Whether they should get fixed is an entirely different issue.
453.3. Jerry Glover (04/25/2006 12:44 PM)
Aha, I see; those silly user expectations again. :-) You're right of course; there are reasons why bugs don't get fixed that are bad reasons.