The Laws That Secretly Control Your Software Delivery

10 February 2025 // Nils Janson

So you think you are in control of your software delivery process? What if I told you that your software delivery process is governed by laws just as the physical world you are living in? In this article, I will explore these often-hidden principles, helping you better understand the challenges and frustrations you may encounter in your daily work. I will offer practical strategies and suggestions to overcome these challenges and improving your teams ability to deliver software successfully.

Laws or mental models

What I will describe are not laws in a sense that implies inevitability as the physical laws. I like to think about these laws as mental models that will help frame and explain what we see in the world of software development. If you understand these mental models, they can be key to better planning, more effective meetings, and great teamwork. They could even lead to a more effective and fun software delivery process, which in turn leads to product success.

The situations and laws

Brooks law: Adding manpower to a late project makes it later

The team is on a roll; we have focus, flow and we have a goal. We feel so productive, we have finally found the space to put our heads down and get to work.  

Then the boss comes in with the great news! They had found two new “resources” that would join the team tomorrow, to help us get back to the promised release date.

So much for focus and flow; now it’s gone. The next days and weeks are consumed by: Setting up dev environments for the new team members( and discovering the documentation is out of date and our machines have been tweaked in all kinds of ways); Replanning to find work for the new resources (which involves revisiting conversations and questions we already dealt with); getting new team members up to speed on domain knowledge, the system architecture and so forth; creating access tickets to various systems; getting to know the new team members and how to work together. The team is back to the storming¹ phase.

After all is said and done, the delivery is four weeks later instead of two. That right there is an example of Brooks law in action!

Adding manpower to a late project makes it later

What can you do when a delivery is at risk of being late? Here are some ways that have worked for me:

• Communicate with stakeholders and managers early and often and you might not arrive at a situation where you are late since you have adjusted the plan.
• Rescope the project, identify what you can deliver and determine if it’s enough.
• Prioritize, only work on the most important tasks, see Little’s law
• Remove communication overhead such as meetings and status reports to give space for the team to find focus and flow.
• Move in people from a team nearby in the organization that uses the same stack and processes and are in the same domain. They are likely to have the access needed, domain knowledge, similar team culture and way of working.
• Pair and/or mob program. This might feel counterintuitive, but it can remove communication overhead like asynchronous pull requests. It will also focus the resources on the most important problem.

Goodhart’s law: When a measure becomes a target, it ceases to be a good measure

“How many pull requests are merged each week for project Parachute?” Once we had the metric in place, the questions came. “Why are there not as many pull requests this week as it was the week before? We should have at least 15 pull requests merged a week!”

We start to create pull requests for every little thing, even for things that should be a unit of work and should have been combined in one pull request. Which leads to that we spend more and more time reviewing pull requests and fixing code conflicts, an extra overhead on our valuable time without crating value in code. Additionally, we incur increased costs due all the extra CI/CD runs.

Goodhart’s law states:

When a measure becomes a target, it ceases to be a good measure

Or restated, when we focus too much on one metric, we start to optimize for that metric even if it means neglecting other important dimensions.

Here are some things you can do avoid the pitfalls of Goodhart’s law:

• Add guardrail metrics to check another dimension of the outcome you are after. In the example above with the number of pull requests, time to merge, or CI/CD costs are others dimensions to track to ensure value is not stuck in the pull request pipeline or costs runs high.
• Focus on the outcome you are after, in this case it’s delivering quality software that adds value for the customers and hence the company.  So customer satisfaction instead of pull requests might be a better metric.
• Once the metric has achieved the desired outcome, move on and focus on a different metric.
• Last but not least, beware of attaching incentives to the metrics. Incentives can cause people to game the system. For example, they may create a pull request per line of changed code if that gives them a pay raise or promotion since they have the most pull requests in the team.

Hofstadter’s law:  It always takes longer, even when you take Hofstadter’s law into account

“How long will it take to replace the third party component? We need to save on the license payment.” After carefully considering the ask from the stakeholder, I used knowledge of the system and component to come up with an estimate. The estimate contains a good amount of padding to account for unknowns.

I give an estimate of four weeks, which I was confident we could meet. Still, after four weeks, there is still plenty of work to be done before we could deliver. Why is that? Hofstadter’s law reminds us:

It always takes longer, even when you take Hofstadter’s law into account.

Several factors conspire to make this so: Life happens - Team members get sick, switch jobs or win on the lottery! We get pulled into new projects and ideas in the organization to provide information or feedback; The complexity turns out to be higher than you thought; And it turns out there is, in fact, a good reason why this is a third party component; And people are involved! And when people are involved anything can happen and will happen (see Murphy’s law); We as humans are not very good at comprehending all the variables that will affect a delivery. There’s so much we don’t know; Software development is inherently a complex task with lots of unknowns and exploration involved; We end up in recursive loops of estimations, development, learnings and so on. Even if you have done something similar before, there is always something that is new, novel or unknown that arises. Our work is rarely a linear, predictable process.

Is there a better way then spending time and energy estimating hours, days, weeks or what have you? Yes, there is!

• Embrace the unknown by iterating and adapting your plan every time you learn something new.
• Communicate proactively, many times the date of delivery is not the thing the stakeholder cares about. In my experience what matters most to stakeholders is predictability of task completion, and that is what they think they get when asking for a date.
• Find ways for your team to continuously deliver value, instead of letting a delivery slide a week or a month, scope down the task and deliver what is possible. It’s better to adjust scope and deliver than push the dates. A benefit is that you get into the habit of delivering value!
• Iterate and adapt. Don’t be afraid to change the plan. Plans should change, or your not learning anything.
• Use historical data, assuming that each task is of similar size. This assumption becomes more accurate over time. There are tools that allow you to to Monte Carlo simulations with that historical data.

Parkinson’s law: Work expands so as to fill the time available for its completion

Or shall we call it the Just one more thing, I’m almost done or I’m soon done law?

A common observation is when arriving at a meeting room on time and there is a ongoing meeting. As soon as I knock on the window, everyone packs up, closes the video call and stumbles out. Apparently there was nothing important being discussed at the end! Or vice versa, where I was the one in the room, quickly picking up my stuff and rushing out with the last conversation in mind, completely forgetting the decision taken earlier during the meeting, which was the purpose of the meeting to begin with.   

Another situation is when you realize the project will be done before the delivery date and suddenly feel the urge to add “cool” and nice-to-have stuff, stuff that might ultimately cause the project to be late. The risk you take when starting something new to fill the time is that you might not have time to finish it. And you end up with multiple tasks in parallel and invoking Little’s law.

Parkinson’s law shows up in many situations such as meetings, projects and tasks and states:

Work expands so as to fill the time available for its completion

Here are some things you can do to take back the time that becomes available when you finish before deadline:

• End the meeting when you have taken the decision, document and share the decision.
• When you are done with a task or project before expected time, close it out, take a break, and then start planning for the project.
• If you are waiting for others, spend the time waiting to learning something relevant for your role or team. It might not be the best idea to start something new, see [[#Little’s law]], ask a colleague if they need help instead.
• Use Parkinson’s law for productivity, set a short timeline for the work and it will be done in that time!

Little’s law: understanding the flow of work

Little’s law² is a very tangible and useful tool when analyzing and optimizing team workflow. This law is a little different; it actually have a formula! I first came across it taking college class about simulation, where we were to simulate wait times for customers arriving at a bank. It took me a while to connect it to the software engineering context where the team (teller) is taking tasks (customers) from a backlog (queue).

Bellow is how Little’s² law looks like when applied to software and lead time, as I want to focus on getting value to customers fast

w = L/λ

Lead Time=WIP/Throughput

Where: Throughput(λ)  the number of items the team can finish in a given amount of time. Lead Time(W) the time from when the team starts work on a task until the task is done. Work in Progress (WIP) (L) the number of tickets the team is currently working on in parallel.

To illustrate how WIP affects lead time, let’s consider an example (assuming the team’s throughput remains consistent).

Scenario with high WIP

Throughput(λ): 2 features/week WIP(L): 8 features in development.

=> lead time = 8/2 = 4 weeks

Scenario with low WIP

Throughput(λ): 2 features/week WIP(L): 2 features in development.

=> lead time = 2/2 = 1 weeks

The example shows that keeping WIP low can dramatically improve your ability to deliver value to stakeholders quickly.

Here are some things you can do to use and explore the impact of Little’s law:

• Experiment and find a balance between throughput and WIP that gives lead times appropriate for your team.
• Start with what your team can control, WIP, keeping WIP low is the easiest way to get lead time down.
• As a strategy to keep WIP low and shorten lead time, start to pair or mob program in the team.
• Use historical data from your ticketing system. There might already be a dashboard in your ticketing system to explore to gain an understanding about your team’s WIP and lead time.
• Talk to your stakeholders to understand what they value most, time to market( lead time) or a “busy” team?

Murphy’s law: Anything that can go wrong, will go wrong

The system had been load tested before the big event, everything looked good then! Still on the big event it went down due to contention over database connections. Now you’re frantically trying to restore service with a bunch of managers looking over your shoulder as thousands of dollars in revenue are lost every minute!

Things happen. And they will keep happening. The systems we work in are so complex that we humans can’t comprehend all its parts. The real world where the system exist is even more complex and messy. Which leads to Murphy’s law that states:

Anything that can go wrong, will go wrong

Something I like to add to this law (which I think I picked up when I did my military service): at the worst possible time

It’s valuable to keep Murphy’s law in mind when you build and design software. Always expect the unexpected and you will design better software. Since we can’t anticipate all the things that can and will go wrong, here are some things you can do:

• Design for failure: compartmentalize to limit the risk for cascading errors for example. Release it by Micheal T. Nygard³ has more patterns and ideas.
• Make a plan for how to act and what to do when things go wrong.
• Keep an eye out for near miss signals; for example, unexplainable errors or problems that you see, but might not affect the system right now. Often, these signals indicate a lurking problem that will emerge under the right conditions. Be diligent as you review error logs.
• Accept that things inevitable will go wrong, and be prepared.

How might these laws interact and affect each other?

Parkinson’s Law, Hofstadter’s Law together with Little’s Law

Some of us get antsy when we finish a task or are blocked due to a dependency, and we immediately start looking for something new to pick up in the meantime, i.e., filling the time (Parkinson’s law). So we start something new, increasing our WIP (Little’s law), which in turn increases lead time and can cause the project to be late! (Hofstadter’s law).

Little’s Law and Brooks’ law

When you add people to a team or project, the WIP (Little’s law) for the team tends to increase, but not necessarily the throughput, and you end up fulfilling Brooks law and Hofstadter’s law.

What interactions of the laws above have you observed and experienced?

Mastering the laws

These hidden forces might not be as rigid as the laws of physics, but their impact on how we deliver software can’t be ignored. The laws, or mental models, offer powerful tools for recognizing and understanding situations and behaviors, allowing us to take action towards a more effective and enjoyable software delivery process.

Pay attention to the secret laws that control your software delivery.