You wouldn’t expect to pay an electrician extra to fix the light switches that he has just installed upside down, why would you pay a software developer to fix bugs?
When being paid to develop software for other people, the issue of paying for bug fixes after development is finished* is often raised. The discussion usually goes something like this: “Thanks for developing the system, it’s great! We’ve found a few bugs, can you please fix them? I don’t think we should pay for the bug to be fixed because the job wasn’t done properly in the first place”. This blog post is an effort to help people understand why this is the wrong way to go.
It’s surprising how often this comes up, especially considering that we never commit to delivering fixed scope for fixed cost. But something about bugs derails people when it comes to thinking about budget.
When it comes down to it, software development is basically the job of incrementally making changes to the code to move closer to a desired end goal. In this respect, fixing a bug is no different to developing a new feature. A bug is something that doesn’t match the desired end goal, so we make some changes to the code to move a step closer to that end goal. At reinteractive, our philosophy is that bugs are just incomplete features and any effort towards fixing bugs is just a regular day at the office. As bugs are raised, we add them to our schedule of work and our clients are free to nominate the priority that fixing those bugs take. It’s best to fix bugs as they come up, but if they are low priority we can push them down the list or even agree not to action them.
Paradoxically, it benefits clients to agree that bugs are regular, charged work. It simplifies the budget process and allows people to work in harmony. If a developer agrees that bugs are not charged for, discussion immediately turns to trying to answer the question of “what is a bug” and the argument of “does this particular instance fit within the definition?”. It is very difficult to define what a bug is whether a particular flaw/feature falls inside or outside of the definition. Any sizeable software project will have dozens, if not hundreds of bugs and having an argument about each and every bug will introduce friction, reduce moral and increase resentment. Not a good basis for a productive and constructive relationship that is oh-so-important for a complex project.
Charging for bug fixing also helps the client set priorities and plan appropriately. If bugs were free to fix once the project concludes, there would be a perverse incentive to de-prioritise any bug fixing as the project progresses and try to tackle them all at the end. This would result in bug ridden, unusable software for a large part of the process, and make it very difficult to judge the effectiveness/usefulness of new features.
Whether you are a software developer building for a client, or a client of software developer services, kick off the relationship with an agreement that fixing bugs is billable effort. Starting your project in this way will give you the best chance for a happy finish* to the process.
*software development is never finished, it is always just “close enough”. ^making bugs is also regular, billable part of the software development process!
