💥 Rethinking the "Padding Game" in Software Development 🎯

I must admit, I've developed a bit of an aversion to planning. The idea of a "five-year plan" often seems laughable, and sometimes even a one-year plan can sometimes feel disconnected from reality.

However, there are certainly moments when looking ahead is necessary. So, how can we strike a balance? What are the strategies that can help us navigate this challenge? Let's explore!

I'm a big fan of Eliyahu Goldratt's "Critical Chain". Over the next few days, I will share my take on some of its insights - as they relate to planning.

Let's kick things off with a fundamental concept: 👉 Estimates.

Any plan hinges on the accuracy of the estimates for its underlying tasks.

When someone asks me for an estimate, I strive to be helpful and ensure I will deliver when I promise. If I believe a task will take about 7 days of work on average, I might add some buffer and give a 10-day estimate to account for normal variations in execution time.

I don't want to deliver late, so had I given a 7-day estimate, I would be likely late half of the time, and early the other half. Not a good look and I hate when others are blocked waiting on me.

Now, imagine that the likelihood of completing this task follows roughly a normal distribution (aka bell curve). That provided estimate likely represents a point where I have a reasonably high confidence (say, 90%) that I'll finish within that timeframe. If I draw a vertical line on the bell curve, 90% of the area should be on the left of the line.

💡 But here's the insight: When you accumulate multiple estimates and add them together, you're essentially stacking up all those buffers. This can lead to a significantly inflated total estimate because you're compounding worst-case scenarios.

Let's take a moment to ponder this. When it comes to executing all the tasks, it's important to realize that not all of them will encounter difficulties requiring extra time. Some will progress more smoothly, while others may face challenges. On average, we'll find ourselves aligning with the median estimations rather than the higher 80-90% confidence estimates.

Statistically speaking, a more accurate approach is to aggregate estimates closer to the median (or slightly to the right of it since software development often leans towards "delivering late" rather than "delivering early"). Then, generously pad the project as a whole to account for uncertainties.

Now that we have more reasonable estimates in hand, our planning focus shifts to managing dependencies 🧶 —a crucial aspect of effective project management in the software world.