Communicating Software Estimates

Chiming in with helpful rules of thumb I go by:<p>1. Never give an estimate in the same conversation in which it was requested, unless you&#x27;re quite sure the answer is &quot;less than an hour&quot;. Especially if they are going to turn around and quote your timeframe to a customer. The reason for this rule is:<p>2. The more you think about an estimate, the higher it will go. &quot;Oh yeah and we&#x27;ll also have to...&quot; is 100x more common than &quot;I found a shortcut that doesn&#x27;t compromise on...&quot;<p>3. Even if they know it&#x27;s an estimate and not a deadline, they might not know the difference between &quot;40 hours of dedicated effort&quot; and &quot;One week&#x27;s worth of business hours&quot;. Making that distinction is just as important as the estimate&#x2F;deadline distinction.<p>I&#x27;m lucky to work where we don&#x27;t spend much effort on estimates and time tracking, both of which just make things take longer and cause productivity-reducing stress.

When I switched from engineering to management, I spent a <i>long</i> time thinking about software estimates, read about many different approaches, and argued with many other managers (I’ll try to write up my own blog post for the next time the topic comes up on here).<p>The framing in this blog post is better than some (it at least discusses uncertainty) but I believe it’s still basically the wrong framework.<p>People (managers) like to assume that estimates are a random variable, and software projects are samples from project space. Estimates can be produced for a project by analogizing it to similar projects. This is not true at all. You cannot reason about software projects by analogy.<p>Some assertions (that I will explore in said promised blog post):<p>- Software development is <i>chaotic</i>: arbitrarily small changes in the input (project requirements, who’s implementing it, stakeholders, team, etc) may lead to arbitrarily large changes in time-to-completion (including “this project is now impossible”). In short, any project may explode at any moment prior to completion.<p>- The risk of a project is particularly sensitive to the engineer implementing it, and depends on that person’s specific knowledge. Have they used these APIs or this database before? Any part of a project that the engineer hasn’t used before represents potentially unbounded technical risk.<p>- the way to manage this risk is to include buffer in the project timeline, and, critically, to use that buffer <i>not</i> for development tasks that were harder than expected, but for re-planning and re-negotiating the deliverables with stakeholders, to un-explode the project. Agile builds this re-evaluation into the project lifecycle, which is the main (maybe only?) thing is does really right.

<i>&gt; When you&#x27;re communicating an estimate the most likely mistake is that the other party considers it to be a commitment.</i><p>The root cause is typically that you&#x27;re communicating it to someone who doesn&#x27;t <i>want</i> an estimate. In that case, communicating the estimate with the commitment is often a mistake unless you&#x27;re willing to negotiate the commitment, because that&#x27;s effectively what it invites.

An estimate is really a probability distribution, that often resembles a Gaussian distribution and thus can be captured with two numbers: the average and the variance. Combining multiple estimates together would involve some math around these two numbers. But the surprising thing is that managers in the software industry don&#x27;t really understand probabilities, and to make it understandable those managers want to reduce the model to just one number, and when this model fails to capture the probabilistic nature of the underlying process, they attempt to overrule the math with authority.

The best estimates I’ve found are “This will take: days, weeks, months, years”. No numeric values allowed. Yes, you can’t do (inherently faulty) math on these estimates to arrive at aggregate metrics: this is a feature. However, it still allows you to meaningfully schedule work.

What is an estimate for? It is really an estimate of <i>cost</i> where big-O is mostly developer cost and that gives a handle on the next part <i>priority</i>.<p>Both of these then add up to an <i>illusion of control</i>.<p>Software is quickly becoming the largest moving part of many many organisations - and trying to control it is likely the wrong approach<p>Software is a form of capital just like a robot on the Tesla assembly line. That robot and the software being estimated in the article are to do a specific job in a specific environment- an investment that will enable more production than without. But all capital rots - or rather depreciates. Taking a nice view you can have 10% on maintenance and repairs (but realistically more than that).<p>Don’t try to estimate these - don’t ask your handyman for a Gantt chart for a hundred tiny fixes - just get them done.

Generally good advice, however I think the actual example phrases could still be clarified, e.g. bg explaining why clear estimates in software engineering are not as common as in other fields — note the person you are talking to might have a completely different experience in their field of work. And <i>then</i> you give your buest guess and a clear explaination of your level of confidence, which factors could lead to shorter or longer project durations.

A more interesting question is how you follow up on your estimates? How can you improve if you don&#x27;t track and reflect on the actual result on what was estimated?

The best way to estimate:<p>&quot;Wild guess - X weeks but could be X+Y weeks for unknown unknowns&quot; (where X is 200% estimate in your mind and Y is 700% of estimate in your mind)

Combining Software time&#x2F;cost estimates with value estimates make it even more fun, because most software is low value (with some chance of being extremely valuable). Combining these into an ROI probability space makes everybody sad, but the expected value is still positive even if the most likely outcome is software that wasn&#x27;t really worth paying for!

Having run a software team with good estimates, I’m disappointed in some of the commentary of, “just make up a long or obscure estimate.” I don’t expect a considerable amount of unknowns to come up in a project unless you have changing requirements or bad planning.<p>You can’t do anything about changing requirements so that can be forgiven. Poor planning cannot though.

Bad companies demand estimates.<p>Good companies just live by a Steam clock.

This article describes some challenges and pitfalls of communicating estimates but doesn’t offer much actual advice.<p>In my experience if you’re talking about risk distributions or hand wringing over the difference between an estimate and a commitment, you’re already on the defensive and not doing your reputation any favors.<p>The better approach is to zoom out and understand the business or product goals, including constraints felt by your stakeholders, and communicate in their terms. Speak confidently to what you <i>can</i> do, with appropriate footnotes for limitations and risks. Even in a low trust environment you don’t succeed by focusing on the negative (though you might want to keep a paper trail), you succeed by showing what you can achieve.