Pay for Bug Fixes? You Bet!

If you haven’t already, register a username for yourself so you can discuss this topic in our Product Testing forum.

An interesting question introduced at an online forum the other day struck my interest. It asked whether it was “right” to have to pay for bug fixes. Not surprisingly, respondents were on both sides of the issue.

Those against the practice laid the responsibility of producing bug-free software onto the programmer – at zero cost.  As expected, the forum’s programmers disagreed in unison. “There is no such thing as bug-free software!” they said. (Well, they said that and a lot of other things I won’t repeat here.)

So who’s right? Are software buyers financially obligated to pay for bug fixes? Are programmers? These questions really can’t be answered without making a number of assumptions, so we’ll get out our coder license and make a few.

Set Up The Premise

Let’s assume…

1. a software product was built according to a reasonably simple spec.
2. its programmer followed said spec.

Next, let’s assume…

1. its buyer attempts to use the software in a way that wasn’t anticipated.
2. the buyer wants to continue using the software in a way that wasn’t anticipated.

The Underlying Reality

Recommended Reading: Testing Computer Software, 2nd Edition

From a programmer’s perspective, the issue looks pretty clear cut. The buyer wants additional functionality and should pay for that functionality. From a buyer’s perspective, all software twists and turns (often interpreted in the buyer’s mind as ‘errors’) can be the result of faulty coding, and therefore, the programmer’s responsibility to ‘fix.’ They’ll say something along the lines of, “Hello. This software doesn’t unleash my favorite marching band when I bang on the desk. Can you ‘fix’ that?”

Regardless of which side you’re on, there’s an underlying reality beneath all the assumptions, all the functionality, and all the misconstrued errors that neither the programmer nor buyer can deny. And that’s the fact that no beast, machine, nor man can fully predict how a person will use software.

Got Infinity? How about E.S.P.?

Who could have ever known, for example, that a buyer might try to load an mp3 into a graphics program? Who could have ever predicted, for that matter, that a buyer would try to calculate binary characters within a spreadsheet? Providing for these unexpected circumstances requires two things that no buyer or programmer has: (1) an Infinity MB drive and (2) clairvoyance.

A software program that anticipates and ‘handles’ every perceived misuse in the world requires zottabytes and zottabytes of disk space. It also requires Sylvia Brown’s input, but the last time we checked, she was indicted on grand larceny!

Plan to Pay

Clearly, there are no winners in this situation. Fortunately, there are some common sense plans of action. Buyers can…

• Clearly explain to their programmer how they’ll use the software they’re buying. They can explain what the software should generate as output, and what it might need to output in the future.
• Prepare to pay for needs they might have missed before, but need now.
• Understand that accommodating new uses will introduce new bugs. Understand that existing code will conflict with new code, especially when existing code was never meant to work with new code in the first place.
• Prepare to pay for those bugs too.
• Realize that the more needs a program satisfies, the more unusable its code gets until it gets a ‘code-lift.’ Just think of an empty room that haphazardly fills with more and more personal stuff (commonly referred to by mom as “junk”). Eventually, the room’s walls are going to crack. Its door is going to burst wide open! The room will need reorganizing. And so it is with software. At some point, existing code will need restructuring to efficiently meet existing and new requirements. And yes, buyers have to pay for that as well because it takes time to restructure – to rebuild – to reconcile new requirements, needs, and uses.
• Do their part in testing. Programmers aren’t the only ones responsible for software testing. Buyers need to properly test software on their systems just as diligently, and report meaningful results. Following programmer instructions and using a consistent set of data during testing are also an important parts of the process.
• Finally, do this over and over until they have the software that works the way they want and need it to work.

If these actions sound too cumbersome, perhaps buyers could alter the way they use their purchased software. Perhaps they could use it the way it was exclusively designed for, for example. Or perhaps they could rely less on automation, rely more on the old noggin, and actually remember to properly format their input files first, for instance.

Those actions don’t cost anything, and the good news is that they require only a little work… a little labor… a little of that stuff some buyers apparently want programmers to do for free.

External Resources:

1. How Google Tests Software
2. Tips, Tricks, Tours, and Techniques to Guide Test Design
3. Lessons Learned in Software Testing