Why Software Teams Need Speed Limits
Reducing the speed limit before a known bottleneck allows traffic to flow smoothly. While we feel we're going slower, we actually get to our destination faster. The same principles apply in software engineering.
It's no fun dealing with roadworks and bottlenecks when you're trying to get out of the city to your holiday destination. This is especially true if you have kids in the back asking, "Are we there yet?"
The road system can't handle that amount of traffic. The result? Sitting in traffic for hours with that stop-start motion, guzzling fuel. A two-hour journey turns into five hours.
In software engineering, we also have bottlenecks that create major problems for delivering features quickly. These bottlenecks often appear during software testing phases, as stories and epics converge into test environments where they can be tested end-to-end. Many people call these environments SIT (Systems Integration Testing).
This is particularly true in large enterprises, where combinations of legacy systems, COTS products, and newer technologies create numerous unknown dependencies waiting to merge into this critical testing phase. While we know ways to test better (early and often in an isolated and decoupled way), the pressure to deliver often means shortcuts are taken.
As quality professionals, we encourage teams to adopt better practices. But it's an uphill battle when teams often throw stuff over the fence to be handled in this testing phase, further exacerbating the problem.
This can be fixed. Advocating for better testing and visualising dependencies is part of the picture, but it requires teams to be given agency, time, and sufficient space to do proper dependency mapping and improved testing in lower environments.
