Fast or Right?
All of us have heard the mantra “Speed, Quality, or Cost…pick any two that you like” but when it comes to a specific software release you are usually only left with the speed and quality levers to pull.
The reason you only have these two is that budgets are generally set annually and even if your budget were instantly doubled you could not hire developers or QA staff fast enough to make a difference on the target release in question. So that leaves us often asking the question, do we want the release out quickly or correctly? In some organizations this question is asked every release. What is the right answer? We believe the single correct answer is “it depends”. I know, that sounds like a copout but really “it depends” on things like what type of software are you are developing, (e.g. shrink-wrapped or SaaS), how tolerant are the customers, how many open production bugs do you currently have, etc. The following is a quick look at some of these dependencies with the intent of informing better decisions regarding their trade-offs in the future.
The type of software you are developing is a critical element in the decision between speed and quality. If you have one shot to get it right because the software is being pressed onto DVDs then we argue that the decision is obvious: you have to skip your delivery date if the quality is not there. If you are developing SaaS type software the question is a bit more complicated because some services are fine to be a little buggy, such as a beta version of a report. Others, like transferring money in a banking application, are not. The user of the software is another critical element in the decision. If the application is for internal sales reps, bugs can be managed much more easily than if the software is for external sales reps.
The current or expected quality of the application is another factor to consider when making the decision to trade speed or quality. If you have very few bugs currently in production it may be fine to release a less-than-perfect version and clean it up over the next week, providing that your customers are tolerant of this type of deployment. It may be the case that the new functionality will rapidly create barriers to entry for your competition or switching costs for your users which in turn may allow for a higher defect density in the initial release. We have often had internal customers tell us this exact comment when we were building features to improve their efficiency or productivity.
When considering the tradeoff of speed and quality, consider your user’s willingness to tolerate defects in a release, the importance of quality in the release given the industry (our example of banking being a low defect need industry) and the business need for speed in the specific functionality contained within the release.