Bug fixes aren’t free

No-one wants bugs in their application but it’s a fact of life. Anyone who tells you they write bug-free code is a liar—they just haven’t found them all yet. When massive corporations, like Microsoft, who have huge resources can’t release perfect software, it should be unsurprising that smaller enterprises struggle too.

However, there’s often a misconception from clients that when they pay someone to write code for them, it will be perfect and free of bugs and if a bug is found at some point, it should get fixed for free. That’s understandable, many clients view custom software development like a product. They forget, or don’t realise, that they’re actually building the product.

What is a bug?

Let’s back up a second and define what a bug actually is. There’s lots of terms used, some people like to call them issues or defects. Wikipedia defines a software bug as ”an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.“

In the end, they’re just a label for the difference between the product you have and the product you want.

What is a feature?

Let’s look at this another way, define what a feature is. It’s a change to the software you need or want to enable your company to operate more efficiently.

In other words, it’s a difference between the product you have and the product you want.

We should be working together

Indeed, during the active development cycle bugs are to expected, everyone accepts that everything won’t be exactly right straight-off. There is some amount of iteration needed to get the software working just the way you want it. You’re looking at that as feature development, because often the “bug” was just that what was needed wasn’t well defined so it was discovered through iterations.

If the client and developer worked together to define, build and test the software then surely they both must have agreed it was good enough to release and begin using. After all, only you, the client, can tell the developer if you believe it is doing everything you need. If you fully tested it then it’s reasonable to assume you would have found any bugs and the developer would have fixed them. If you authorised the developers to release the software and you paid them then you tacitly agreed it was good enough to use.

If you took my previous advice, then payment triggers the ownership clause in your contract. You now own the software in the state that it’s in. You’re reaping the benefits of the new software and you own the bugs.

That’s why, if you want the bug fixed, just like if you want a new feature developed, you must pay.

The problem is that while technically you might agree with this, having followed the logic, it’s not a satisfying conclusion. The reality is, that you were busy, and you’re not an expert. Everything seemed ok and you didn’t necessarily realise what you were signing up to.

While it might be satisfying for me as the software developer, it certainly doesn’t leave me with a good taste in my mouth. I want superlatively happy clients, and this result isn’t going to make them super-happy.

This article is the first in a series where I’m going to unpack and explain the whole development lifecycle process to make sure all parties come away feeling great.