It’s inevitable that bugs will be created during custom software development projects. And it’s not unusual for clients to have the mindset that the development team should “pay” for the bugs.
But punishing the team for bugs is penny wise and pound foolish. As a client, you should have the responsibility to pay for bugs, and the team should have the responsibility to learn from bugs.
Mismatch of Mindset
Whether working with an employee or a vendor team, it can be easy to slip into the mindset that a sprint delivery or release point should come with a guarantee against bugs. As a client, you have the expectation of getting what you paid for. I believe confusion comes from a mismatch on what is actually being paid for. Custom software development should not be confused with buying a finished product like off-the-shelf software. When you buy a finished product, the majority of risk is driven out of the product. The seller can tune pricing to cover cost and leave margin for future development, maintenance, and bug fixes. You should expect a mostly bug-free experience, as the product should have been created using quality practices and gone through testing phases. Bugs should be fixed for free as part of the purchase price. When you are paying for custom software, you should have the mindset of paying a team to design and develop the very first instance of a product. The effort is ripe with risk, including:
- Building the right product.
- Funding and schedule risks.
- Third-party integrations.
- Technical approaches that need to be proved out. You are paying your team to help you mitigate these risks, not to financially own them. Each sprint or release is not a guarantee of a finished, bug-free product. The team should do their best to build a high-quality product. Quality is created in the short term through design and testing practices. Quality is created in the long term through insights gained from exploratory testing, pilot releases, and public releases. Treat bugs as inevitable discoveries that occur at a longer cycle time in the development process.
Caveat: Have a Team You Trust
You should only be willing to pay for bugs if the development team is pro-actively focused on quality. The development team should be:
- Disambiguating features and building the right product.
- Creating automated test suites that have high code coverage.
- Using continuous integration to frequently build the application and run test suites.
- Complementing automated testing with manual, exploratory testing.
- Automating tests for any bugs discovered to ensure bugs are fixed and remain fixed. If your team is working in good faith and employing practices that promote quality, view bugs as necessary product development work that happens downstream of initial execution. And if your team isn’t using practices that promote quality, fire your team.
Penny Wise, Pound Foolish
When clients believe they are getting an implicit warranty with each sprint or release, I’ve heard the following requests:
- As a vendor, you should pay for fixing the bugs and keep the project on schedule.
- As an employee, you should work extra hours (for free) and keep the project on schedule. Both of the these requests are a form of punishment that puts you at odds with your team. The team uses best practices and their professional judgement to balance delivery and quality. Penalizing the team for bugs perverts their professional judgement because it over-stresses quality. If you penalize a team for bugs, they will move more slowly. It’s likely the team will continue to brainstorm and develop automated tests beyond the team’s general sense of diminishing returns. Manual testers will also work beyond their general sense of diminishing returns. Punishing the team for bugs also creates an incentive for the team to not identify bugs during development. Bugs and quality issues may be silently deferred and surface later in the development schedule when it is harder to manage the situation.
Embrace Bugs and Embrace Risk
If you want to build a quality product, embrace the fact that there will be bugs. Encourage the team to identify bugs and get them into a backlog. Get aligned on when to estimate bugs and prioritize them against new feature development. Feel good about funding a team of smart designers and developers to do their best at predictably building your product. Feel good about the learning cycles that occur and how quickly your team integrates new insights. Be aware that the financial risk of developing custom software is in your hands. A warranty doesn’t come from your development team, but it’s what you will offer to your customers. Taking on the financial risk is why you have such a potentially significant financial upside.