Four Things Traffic Flow can teach us about software development
Software Development is a game of flows (?)
Developing software is a game of flows. From the ebb and surge of task completion to the rhythmic pulse of deployment cycles, our work follows patterns eerily similar to traffic systems (yes, I’m stretching metaphors). And just as with highway congestion, our intuition about software development flows often leads us astray. In my previous article, I explored how queueing theory challenges our assumptions about productivity and efficiency in software development. We discovered four counter-intuitive lessons: avoid 100% utilization, limit work in progress, favour single-piece flow over batching, and focus improvements exclusively on bottlenecks.
Today, I want to take us deeper into traffic-inspired systems thinking with three phenomena that might change how you organize your development processes.
Let's explore how traffic shockwaves, merge strategies, and counterintuitive network enhancements might be the key to unlocking smoother, more productive software delivery.
Traffic Shockwaves
Even in well-functioning, queues (e.g. not fully utilized), small changes can have big impacts.
In 2008, researchers ("The Mathematical Society of Traffic Flow", Yuki Sugiyama et al., New Journal of Physics, 2008) conducted a fascinating experiment. Twenty-two drivers were asked to drive around a circular track at a constant speed (a seemingly simple task!). Everything ran smoothly at first, but then something happened: minor, almost imperceptible variations in individual driving speeds began to amplify, eventually creating a backward flowing "shockwave" that caused traffic to bunch up and completely stop in sections.
This phenomenon mirrors what happens in software development. An unexpected sick day, a longer code review or an API that doesn’t play ball can all create ripples that amplify across the development life cycle. These small disruptions don’t just add their own delay; they create compounding effects that cascade through the delivery pipeline.
This explains one of the most frustrating aspects of software development: why seemingly insignificant events can derail sprint commitments and why deadlines that appeared comfortable suddenly become impossible. It's not just about the direct impact of these events: it's about the shockwaves they generate throughout your system.
The art of the merge
When multiple lanes of traffic need to merge, most drivers immediately switch to the open lane when they see a warning sign. This seems courteous and proactive, but traffic engineers have discovered it's actually the worst possible approach.
Remember what we learned about queue utilization? As it approaches 100%, wait times approach infinity. By abandoning one lane prematurely, you're artificially creating a 100% utilization scenario in the remaining lane. By moving early, you're dramatically increasing utilization in a particular lane while leaving another completely unused.
The optimal approach—known as the "zipper merge"—requires using both lanes to their full capacity, merging only at the final point where lanes actually narrow. This counterintuitive strategy has been proven to significantly reduce traffic backups.
How often do we adopt "early lane changes" in our processes? Do we pre-emptively abandoning effective practices when we encounter the first sign of trouble? When a release causes problems, the instinct is often to slow down all releases (can't go wrong if you don't release!). When merge conflicts arise, teams sometimes institute elaborate branch management strategies rather than addressing the root cause.
These reactions feel right, just as early lane-changing feels considerate. But they create artificial constraints that dramatically reduce throughput. The better approach is to use your capacity fully and address integration points directly, not prematurely.
Braess’s Paradox - when improvements make things worse.
Perhaps the most mind-bending traffic phenomenon is Braess's Paradox, which demonstrates that adding a new road or shortcut to a network can sometimes increase overall travel time for everyone. This occurs when the new route attracts too many drivers who abandon previously optimal paths, overloading critical intersections connected to the new route.
Here's an example. We have two different ways of getting from Start to End (either Start → A → End or Start → B → End). The Start → A and B → End routes slow down as more cars use them (the travel time is 10x the number of cars). Route A → End and Start → B are both fixed costs that take 50 minutes. The travel time on both routes is about 80 minutes on the average (assume we have six drivers). We now add a short-cut with a new route from A → B. Each driver now makes the same rational choice to take the short-cut, but now (since it changes with load) it ends up taking longer for everyone.
In software development, this manifests in countless ways. Adding a new tool to "streamline" development often creates more complexity than it solves. Creating shortcuts in the development process (like skipping code reviews to speed things up, or adding more people to a late project or implementing a "fast track" for urgent features) typically introduces disruptions that slow down the entire system.
This is why Conway's Law (systems mirror communication structures of the organizations that design them) and Brooks's Law (adding manpower to a late software project makes it later) both hold true in practice. Local optimizations often create global degradations, particularly when they introduce new integration points or communication channels. The remedy lies in systems-thinking: approaching your development process as an interconnected whole rather than isolated components. Before adding that tempting new shortcut. be it a tool, process, or organizational structure. consider how it might impact flow across the entire system, not just at a single point.
Conclusion: Embracing Counterintuitive Wisdom
Traffic theory offers software teams another metaphor for understanding flow, congestion, and optimization.
Respect ripples: Minor disruptions create magnified consequences through shockwaves. Build buffers and resilience into your planning rather than assuming perfect execution.
Merge sensibly: Use your capacity fully and address integration points head-on rather than pre-emptively avoiding them. Sometimes the "polite" solution creates more problems than it solves.
Shun shortcuts: Adding new paths often increases congestion rather than relieving it. Simplify systems rather than adding complexity, even when the complexity appears to offer advantages.
Optimize systems: Local optimizations frequently lead to global degradations. Consider the entire flow before implementing changes.
The key isn't working harder or adding more resources, it's understanding and working with the mathematical realities that govern all systems of flow, from highways to pull requests.
Remember the goal isn't to go fast in short bursts, it's to maintain a steady, predictable speed throughout the journey (be it the Easter bank holiday traffic or delivering software!).