Today, I’ve been trying a thought experiment. It is designed to help us find creative solutions to software production bottlenecks.
Imagine that you’ve landed a job in traffic management, and that you’ve been assigned the task of reducing average journey times. What are your basic options?
In a couple of minutes, one of my colleagues and I came up with a few ideas:
- Get everyone to drive faster
- Increase the number of lanes
- Remove obstacles, e.g. traffic lights, roundabouts
- Add additional routes
- Reduce congestion by reducing the number of vehicles on the road
- Encourage people to avoid rush-hour by spreading their journeys throughout the day
- Stop-starts create traffic jams, so slow traffic so that it flows better
- Add safety features to cars so they’re less likely to have accidents and cause delays
What else can you think of?
Now, imagine that delivering software works in a similar way. The features are cars, and the road is the delivery pipeline that takes feature requests and turns them into deployed features that are used by our customers.
Based on this analogy, what kinds of changes could we make to the development pipeline so that we could deliver features quicker?
For example, “get everyone to drive faster” could map to, “get everyone to code quicker”, and “increase the number of lanes” could map to “add more developers”.
- What are the flaws in this analogy? In what ways do getting cars from A to B differ from getting features delivered?
- In what ways is the analogy helpful?
Personally, I found this thought experiment helpful, as it helped to generate different ways of looking at the software development life-cycle. It helped me to come up with ideas that could help increase our productivity.
The down side of this approach is that, like any analogy, it breaks down if you push it too far.