When is a bug a feature?

Posted by Ben Simo

Ever find a bug that "can't" be fixed?

I am not referring to fixes prevented by technical or schedule limitations. I am referring to bugs that have become expected features.

Here are two...

Experience #1
I once found a bug in communications software that would cause most of the systems likely to be on the other end of a connection to crash. I don't mean the failure of a single process. This was a memory allocation issue that could take down entire systems that were essential to their owners. An argument could be made that the bug was really in all those other systems and not in the system that I was testing. However, most of the large number of systems that made up the pre-existing installed base could not create the condition that would make another system fail. Due to the large number of systems (from a variety of vendors) it was determined that the condition that caused the failure should be prevented by new systems (and future releases of existing systems) instead of immediately fixing all the old systems. When I discovered the problem on the new system, the developers were willing and able to make a quick fix but the business said no. The reason? The manuals had already been printed and the application could not be changed in any way that changed the documented user experience.

Experience #2
After being newly assigned to test a product that had been in "maintenance" mode for many years, I discovered and reported numerous bugs. There were also new developers assigned to this product. The developers and I were allowed to work on these long-standing defects because the new developers needed a chance to familiarize themselves with the code before working on upcoming enhancements. One of the bugs we fixed was a yes/no prompt that required that users select "no" when they meant "yes", and "yes" when they meant "no". To both me and the new development team, this was a major problem. However, after shipping the "new and improved" release, we received requests from a customer that the yes/no prompt be put back the way it was. The reason? The customer had created their own documentation and training for their users. The customer was teaching their users that "yes" means "no" and "no" means "yes". We had to back out this change to keep the customer happy.

Some lessons I learned from these experiences are:
1) There are often bigger issues involved in software development than removing all the bugs.
2) Users learn to work around bugs and treat them as features. This can create a situation in which the fix to a bug becomes a new bug. Consult users before making changes that impact their workflow -- especially users that write big checks.
3) Delaying a fix for a bug that impacts how users behave may prevent the bug from ever being fixed. Had the yes/no issue been fixed soon after it was first introduced, the customer would have been happy with the fix. You may end up needing to manage two sets of code: one for customers that want the bug fixed and one for customers that want the bad behavior to stay.
4) Respectfully ask questions when direction doesn't make sense. Work with stakeholders to come up with creative solutions. In the case of the pre-printed documentation, development was able to come up with a creative solution that did not impact the user interface or documentation.

What "non-fixable" bugs have you encountered? Was a solution found?