How To Reduce Bottlenecks In The Software World
4 Ways To Increase Productivity

“Traffic congestion adversely impacts quality of life and economic productivity in metropolitan areas. It increases fuel consumption, the cost of traveler and freight movement, the number of crashes, and tailpipe pollutants harmful to human health.” — John C. Falcocchio
To the naked eye, the traffic jams and congestion are often unpredictable and appear chaotic. Indeed it is, but if we take a moment to think about it a bit further, traffic jams are even more complex beneath the surface. For example, a car accident creates unexpected delays for people commuting to/from work and business deliveries as well as other exponential flow on effects throughout society. John C. Falcocchio, the author of The Cost and Other Consequences of Traffic Congestion, wrote about how “traffic congestion adversely impacts quality of life and economic productivity in metropolitan areas”. Software development also experiences traffic jams which have associated costs and consequences.
Traffic jams that cost big dollars
I will be brief here because I imagine that many are already aware that “traffic jams” in software development are costing us money. As this is not a complete list of “traffic jams”, I do encourage you to share in the comments below examples of “traffic jams” experienced when developing software.
So, here are some of the traffic congestions I have commonly observed and experience in the software world:
- Spending time on the wrong priorities (Whilst this seems obvious, they are often not obvious to detect.)
- Unnecessary complexity (eg. Building test in a throwaway prototype)
- Code that has a steep learning curve (eg. Over optimisation in architecture)
- “Diffusion of responsibility” — When we assume that someone else was going to take the action so we do nothing, but in fact our assumption is often wrong.
- Poor coordination of work (eg. Too many developers working on the same area of the application in parallel causes problems such as merge conflicts)
- Adding more people to speed up a project (see “Brook’s Law”)
- Broken communication leads to increased misunderstandings and errors
- Teams across different time zones that don’t have an effective method/channel for communication (Research shows that communication costs are likely to increase with organisational distance.)
- Overload of work (eg. people become focused on the “doing” to meet the deadline that they miss out on thinking critically)
- Knowledge loss and gaps (Whilst this seems obvious, they are often not obvious to detect.)
Before you ask “so what?”, bare with me. I recognise that you might already be aware of the traffic jams listed above but the purpose is to ponder how much is it costing your business and what might be more expensive than expected when developing software. That is the real unanswered question, I believe from over 10 years in software, and it still poses to be a big challenge in actually tackling the traffic jams effectively in the software world today.
How could you improve the way you use {technique/method name}?
Next, I’ll share a few techniques to get you started. Some you may already be familiar with but I would kindly recommend that you take this as an opportunity to ask “How could you improve the way you use {technique/method name}?”. I will also touch on a few more complex but reliable techniques that fill the gap in the existing software practices.
Ways to reduce the congestion
It’s about doing it well and continuous improvement.
Traffic jams and congestion in the software world can easily be reduced. We already know this because we have been attempting to improve our software development practices for the past (almost) 8 decades. But it’s important to recognise that its not just about “doing it” but its about “doing it well and continuous improvement”. It’s also worth noting that we will never be able to eliminate the congestion because of the pure nature of software development — it’s a constant “learning activity” and an exercise driven by people who have natural social biases.
Let’s take a look at 4 basic techniques that we should be constantly improving to do well.
1. Don’t assume, ask “the right” questions
Obvious, I know. But the nature of the chaotic, fast-paced and dynamic software development environment detract us from asking questions. Consequently, we make assumptions more often than we’d like to admit because we allow our intuition to take control. As humans, we love taking mental shortcuts (aka cognitive biases). This means that we repeatedly miss out on opportunities to think critically. Thus, asking one or many questions could prevent you from going down a long, stressful path that did not need to be travelled. More importantly, asking “the right” questions help to minimise “traffic jams” in software development. But knowing which questions to ask requires training and practice because asking “the right” question is not easy. Entrepreneur Rick Smith, founder of World 50, wrote:
“Today’s leaders are addicted to answers. … Of much greater value will be the ability to ask the right questions. In a chaotic situation, winning requires focus, and knowing where to focus will be determined by the questions you are asking. In the future, your effectiveness as a leader will be defined by your ability to ask the right questions.”
Adam Tornhill, author of Your Code as a Crime Scene, described a useful interpretation of Conway’s Law in the form of a question: “Given a proposed software architecture, how should the optimal organisation look to make it happen?”. This question is a useful organisational tool to enable us to design the shared parts of software products to be more inline with the structure of the organisation. Having said that, here are a few other example questions to get you started:
- Do I/we have the right team?
- How do we predict knowledge loss if a team member leaves?
- Are we measuring the right performance indicators (for the team, product, etc)?
2. Predict bottlenecks and future outcomes
As we may already know, being wrong or late when developing software is an expensive activity. This results from the expensive activities being “invisible”. However, if we could predict both bottlenecks and future outcomes, this could save businesses significant money.
A decade apart, Melvin Conway then Fred Brooks each published research showing that there is a link between our organisation and the way we design software. This was introduced as Conway’s Law and Brook’s Law respectively. The point here is that extensive research demonstrates that there’s a lot can be discovered and learnt from the code we write. Hence, we can use code to predict bottlenecks. Here are some examples of “what” bottlenecks we can predict:
- Defects
- Breakdown in communication (eg. merge issues)
- Poor coordination (eg. many developers working on one area of code base)
- Where and what development practice to improve
- Temporal coupling
- Technical debt
On the other hand, future outcomes can be predicted by taking a scientific modelling approach, the same kind used by statisticians and actuaries. Whilst its more complicated, it provides a reliable way to the chance of each outcome occurring given different scenarios. As this involves rather complex techniques that I will not go into detail here but instead sharing some examples of what we can predict. Here’s what we can learn from modelling, hence predicting future outcomes:
- What we should invest in a project given the expected/desired ROI?
- How much is a feasible investment for a project?
- When we will lose our “window of opportunity”?
- When we will exhaust an investment based on spend, software development and software delivery?
- How much could it cost if we wanted to “go faster” (aka increase speed of software delivery)?
The ability to predict bottlenecks and future outcomes can significantly reduce cost and increase software development productivity. Interested in learning how to do this for your business? Send a message to hello@criticide.com
3. Uncover expensive practices
We frequently mistaken the feeling of making an attempt for an appropriate execution to solving a problem. Because of this, it is not easy to identify the practices in software development that are the most expensive. For example, why do we not compare the cost of our actions to build one set of features over the other? Or why do we not compare the probability of a certain outcome happening over the probabilities of two other alternatives? The short answer is that we perceive it to be too hard and, naturally, we’re ignorant.
Uncovering expensive practices requires relatively more complex techniques of measuring and analysing which cannot simply be explained in a list steps or article, because it involves extensive mathematics, customisation and critical thinking. Instead, I will share some of the opportunities (but not limited to) that can be uncovered:
- Risk of knowledge loss across and within our teams developing software
- Knowledge barriers amongst a development team due to the mental maps (aka “subjective views”) individual create
- “Code churn” (the rate at which code changes) to identify the hours spent on complicated merges — was this avoidable?
- Bottlenecks, eg. parallel work due to poor coordination
- Where development practices need to be improved
- Potential process loss
Ultimately, uncovering the expensive practices within your product development process and business involves a thorough understanding of the problem (not symptom) and assessment with credible evidence, skills and experience. If I may make a suggestion, reaching out to someone who’s done it before is always a good starting point (check out Criticide).
4. Don’t trade precision for simplicity
“We trade precision for simplicity…but…there’s always a risk that we may draw incorrect conclusions.” — Adam Tornhill
When we rely on our intuition and mental shortcuts (System 1 thinking), “we trade precision for simplicity”. But in doing so, “there’s always a risk that we may draw incorrect conclusions”. So whilst simplicity is good for some things, it is not good for all things. The same goes for precision. In the world of software where uncertainty is king, it is crucial to know where we need precision over simplicity. Below is a taste of some of that uncertainty that we face on a daily basis where precision matters:
- How much capacity can my team delivery?
- Will we make the deadline?
- Is it reasonable to expect that we could deliver Product X with an investment of $1M?
- Could we deliver Product X faster by investing an additional $250K and/or adding X additional team members? (Note usually a bad idea to just do both unless you have credible evidence.)
- What is the dollar value associated with the risk of taking action A?
In the end, it comes down to how we choose to develop software. Building successful software products is highly correlated to how well we can manage uncertainty. This includes putting our critical thinking cap on so we know when need precision over simplicity.
Kill The Distractions
If we think of developing software like taking on a road trip, we’re eager to get to the destination. So taking a known route compared to unknown/uncertain route is preferred. However, in software development there is no such thing as a known route. Hence, we need to be strategic about how we navigate the uncertainty. Wishful thinking will not get you very far, but by removing the distractions (eg. lack of communication, coordination, unclear goals, etc.) and thinking critically, we set ourselves on a path to more sustainable software development.
“Programming is a learning activity. It’s ironic that we have to make so many fundamental design choices early, at the point where we know the least about the system.” — Adam Tornhill
Unlike the certainty of driving from point A to B with Google Maps, “programming is a learning activity. It’s ironic that we have to make so many fundamental design choices early, at the point where we know the least about the system.”
Feel like you might have one or more traffic jams that you’re interested in getting rid of? Drop us a message at hello@criticide.com to explore how we can help.
Learned something? Click the 👏 to say “thanks!” and help others find this article.
Hold down the clap button if you liked the content!
Clap 50 times!

