The Theory of Constraints
Most processes are dominated by a single bottleneck. Focus your improvement efforts on that bottleneck for best results.Complex systems, like groups of humans, or microservices architectures, are, well… complex.
As such, understanding such a system can be quite difficult. We need tools that allow us to simplify, or focus on simpler parts of the complex system one at a time.
One such tool is the Theory of Constraints, a management paradigm that views any manageable system as being limited by a very small number (often one) of constraints.
It has broad implications for software development and delivery, but let me illustrate with a simple example related to cooking.
Imagine you’re preparing a pot roast, with a side of boiled carrots. Boiling carrots takes 5 minutes. Cooking the roast takes 4 hours. You have roughly three options for the order in which you prepare your meal:
- Boil the carrots, then cook the roast. Total prep time: 4:05 (and your carrots will be cold)
- Cook the roast, then boil the carrots. Total prep time: 4:05 (with warm carrots)
- Cook the roast, then 5 minutes before it’s done, boil the carrots. Total prep time: 4:00
Other than the first option, which gives you cold carrots, there’s no substantial difference between these options. The 4-hour cooking time for the roast dominates the prep time, no matter what order you operate in.
This is the dominant constraint. Unless we can find some way to reduce the pot roast cooking time, we’re stuck with a meal that takes at least 4 hours to prepare.
Most of the time, we have a similar constraint in software, too. Page load times are usually dominated by a single process (such as a database query). Software delivery time is usually dominated by a single process (such as manual QA).
If we want to optimize these systems, it’s important to focus on the dominating constraint, even when that’s hard to improve (or impossible, as the case of a pot roast). All other efforts will generally yield little to no improvement.
