Software application development is an inexact science. We write code and build software products full of defects. If we are lucky, we are aware of the defects and can catch them before they go to our customers. Engineering teams often feel they are in an epic struggle to build the perfect product while dealing with ever-changing requirements and product specs, framework changes, and evolving infrastructure.
An engineering team’s objective is to make forward progress on building their product while keeping their product quality “good enough.” The definition of “good enough” is defined by company values and the context surrounding the product. A hardware device with a slow update cycle has a significantly higher bar than an iPhone app that can be updated quickly. Different companies have different quality bars as well—Instagram pays a significant amount of attention to small visual design problems, creating in a product that feels extremely polished and well crafted. This variability in the definition of a quality bar, from company to company or product to product, can be overwhelming. People give up, resulting in the complete lack of a defined bar, or a quality bar where every software bug is a blocker.
[…] A systematic approach to product quality can help produce a product that is a joy to use, a product that feels polished and fast, one that customers keep returning to over and over again. Regardless of how bad things are today, you can institute a framework to pay off your bug debt, while building and pushing features. An SLA system has built-in checks and balances to slow down feature development when things get serious and provides natural incentives for teams to pay attention to the quality of their software, leading to more productive and happier engineering teams in the long run.
Source: Rushabh Doshi, “Software Quality, Bugs, and SLAs”, https://rushabhdoshi.com/posts/2019-10-18-software-quality-bugs-and-slas/