Published · 5 min read
Estimating software projects is basically the tech equivalent of arguing about Irish weather. Everyone has an opinion, nobody really knows anything, and the forecast changes all the time. One minute you're looking up and see that nice blue sky, and fifteen minutes later you're sprinting through sideways rain wondering why you ever trusted an umbrella in this country. If you get sideways rain, you get wet. Like really wet.
That's why we don't rely on umbrellas. We rely on raincoats.
A raincoat doesn't stop the rain. It just means the rain can't stop you. Software development isn't much different. The only way to survive the chaos is to embrace it the way we embrace Irish weather: with humour, realism, and the right gear. In this post, we'll look at what those raincoats are: practical tools and approaches that help us handle the unpredictability baked into every project.
Most bad estimates are bad conversations. And before getting into the specifics, it's worth naming that directly. Psychological safety is supposed to mean people can speak honestly without consequence. In practice, it gets used the other way: as cover for pressure, wrapped in the language of openness and trust.
Estimation Accuracy
Sometimes the people talking loudest about psychological safety are the ones making it unsafe to give an honest number. The pressure is rarely explicit. It's a raised eyebrow on a call, a follow-up message that carries a clear expectation, a silence that says the answer was wrong before anyone responds. Engineers learn to read these signals fast. They give the number that ends the conversation. That number is almost always wrong. It distorts estimations, sets unrealistic expectations, and jeopardises the project before the first line of code is written. A team that can't say "I don't know" is standing in sideways rain holding an umbrella.
One effective raincoat is the classic: divide and conquer. It works almost everywhere. Breaking down complex projects into smaller, more manageable tasks decreases the number of unknowns and reduces dependencies on other teams or departments. It lets you assess each component more granularly, which makes it easier to give estimates that actually hold up.
Even so, estimation accuracy can remain elusive. Here's why.
The term unknown unknowns captures one of the biggest challenges here. These are the things you don't know you don't know: hidden pitfalls, unforeseen complications, or external factors that can blow up your timeline and budget without warning.
No matter how well you plan and break down a project, there will always be unknown unknowns lurking. They're surprises waiting to happen, and they can throw even the most careful estimates off course. No raincoat covers everything. But knowing that going in changes how you pack.
Identified request to simplify paragraph while preserving linkWhat you're estimating today might not exist in the same form next week. Requirements shift, priorities change, someone discovers the third-party service you were counting on doesn't do the thing you thought it did. New tools change what's hard and what isn't. The estimate doesn't go wrong because you estimated badly. It goes wrong because the thing you estimated changed.
External dependencies, often involving other teams, departments, or third-party services, introduce significant uncertainty into estimations. To mitigate this, I generally try to do the following:
Where you can, cut the dependency entirely. Find an alternative path, own more of the stack, do without the feature. That's not always possible, but it's always worth asking first.
When you're stuck with a dependency, get in front of it early. Find out when the other team does their planning and get your ask in before that window closes. A request that lands during planning becomes a prioritised ticket. The same request a week later becomes an interruption, and interruptions get deprioritised. Once you're in, check in. Not obsessively, but enough that it doesn't quietly slip off their board while you're not looking.
Getting your project into the planning cycles of your dependencies early minimises surprises and gives you a fighting chance at a realistic estimate.
The goal was never to make estimation perfect. It was to build teams and processes that can absorb the unexpected without losing momentum.
None of this is clean. The most useful thing you can actually do is make the uncertainty visible rather than hiding it inside a number. State your assumptions out loud. Do the post-mortem even when it's uncomfortable. And stop treating a revised estimate as a failure. The estimate was always a guess. Now it's a better-informed guess. That's progress.
The point is not to stop the rain. The point is to stop pretending you can. Get good at moving when the forecast is wrong because in software, it usually is. That's the raincoat. Wear it.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。