Accuratizing Software Estimation
De-vaguifying technology product schedules
This article is exclusive to Pointer — a reading club for developers.
Sign up at Pointer.io for our weekly newsletter.
One of the most difficult things for modern software companies to deal with, besides cleaning up after dog accidents in hip, pet-friendly offices, is predicting the cost and implementation time for products that they make. Executives and marketing people ask the simple question, “How long will it take?” and always get back unhelpful answers ranging from, “I don’t know,” to “We don’t even know if it’s possible yet,” to probably the worst answer, usually given by an engineer, “n weeks.”
Of course, that last answer is exactly what the executives wanted, which is why the engineer provided it. But n weeks later, the product will not be finished, which results in a follow-up query and a resulting “m weeks,” where m is usually (but not always) less than n. But this new estimate will also prove to be incorrect, and so the iteration continues.
This problem is well known in mathematics, where it is represented as an infinite series:
where each individual estimated duration di adds to the previous total and can be used to complete the final duration D, as follows:
This equation tells us that the actual duration D that the executives are seeking is simply the sum of the infinite estimates given by the engineering team over time.
Of course, if we knew what those estimates were going to be, we could easily calculate D, but since the series is infinite, this might take a while*. Besides, math is hard and Greek symbols tend to be a turn-off for executives that only want to see numbers. So we will seek our answer through further estimates and assumptions.
*Approximately forever
The initial answer given by the engineer was reasonable, given their knowledge of the problem domain at the time. It’s just that engineers are always optimistic, accounting only for how long something might take in the best situation, with the best minds, where nothing goes wrong and management leaves them the hell alone. But this never happens in reality, so we need to apply our knowledge of typical software product schedules to derive a more accurate answer. We accomplish this with the tool I call Estipad:
Estipad™: A realistic and totally reasonable sequence of estimation padding multipliers that fully account for real-world engineering situations.
Note that these padding factors are multiplicative, not additive**. This subtle but important distinction accounts for longer estimations having more variability. For example, if one were simply to add two weeks for vacations, this would only work if the project were to take five years (assuming the typical situation of engineers forgetting to take vacation). But if the project were much longer, then two weeks would not be nearly enough. Multiplying allows the padding factors to be proportional to the overall duration.
*More math terms
Following is the set of Estipads that I use when creating proposals for my clients. Your situation may differ, and you can add in other Estipads of your own, but I would counsel against removing any, or making the factors smaller, as these are derived from real-world data of projects that maximized client cost while minimizing consultant risk.
- Optimism: Engineers think they’re better than historical data indicates.
- The unknown: Random things can happen in any organization. Maybe an earthquake caused outage in a data center. Perhaps a bear got into the break room one Friday and ate the boxes of Motivation Donuts™. The engineers might all be stricken with simultaneous cases of amnesia. We just don’t know. Factor it in.
- Time off: Engineers typically don’t take vacations, because work is actually their vacation from home. But maybe they need time off to recover from finger cramps. Also, management and project managers take vacations, and how can engineers stay on track when other people aren’t constantly asking them for updates?
- Team offsites: Nothing creates better productivity than motivation***. And motivation clearly comes only from artificial, team-building offsites scheduled by department admins. If we want the engineers to deliver the product, we have to account for the time lost to engendering a false sense of team loyalty.
***Citation: Survey results from motivational seminar attendees. - Meetings: Where would organizations be without meetings? From communicating status, to listening to status, to pretending to listen while trying to remember status, meetings are a critical part of product development. The more meetings there are, the more productive the organization is. But time spent in meetings (including requisite pre-meeting meetings and meeting-postmortem meetings) detracts from time actually spent writing the product code, so we factor it in.
- Mentoring: A healthy organization is constantly hiring and growing new talent. But these new people don’t know the important things about their new roles, such as when meetings take place or how exactly status should be communicated in meetings. The company needs to draw upon the vast experience and limited time of the experienced engineers to train these new recruits in the ways of the organization.
- Turnover: It is a fact of corporate life that engineers will leave the company, often citing irrelevant excuses such as “Too many meetings!” and “Way too much bureaucracy!” This dynamic should not be seen as a negative, but rather it should be rationalized with upper management as an opportunity for the organization, paving the way for fresh energy and cheaper salaries for new employees. This item is related to the previous Mentoring item, because turnover creates places in the group for new talent, which must be mentored. But there is additional overhead specific to turnover in terms of the time that the group must spend recruiting, interviewing, and going to Welcome and Goodbye lunches.
- Re-scoping: Engineers always take the customer at their word. If the client tells them, “We need an app that allows our users to record audio notes and convert them to text,” the engineer will interpret that literally. And when they deliver an early prototype performs exactly to spec, they will be faced with the unpleasant reality of underlying and changing client needs. Because when the client specified recording and transcribing, what they were also implying was that the app needs to handle all known languages, including Esperanto, and that the audio notes need to be synchronously uploaded to a server (which also needs to be written) and that the text transcriptions need to be appropriately encapsulated in Sarbanes-Oxley-compliant documentation and mailed out (in triplicate) to appropriate federal agencies. So the project needs to be re-scoped and the implementation time lengthened accordingly.
- Fudge Factor: Finally, there is simply the fact that our estimates and multipliers above may be wrong for circumstances beyond our control. There’s nothing worse than under-estimating the schedule, especially if that means under-billing for the job. So we add in a final fudge-factor to account for these inherent inaccuracies.
Each of these Estipads is a multiplier of two (2), which leaves us with the following formula:
Estimated Duration = Engineer’s Estimate * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2
which simplifies to:
Estimated Duration = Engineer’s Estimate * 512
For example, if the engineer comes back with an estimate of one week, you know with some certainty that the actual duration will be closer to ten years. But just to be on the safe side, you should round up to twenty years and bill the client accordingly.
When an engineer tells you a project will take a week, you should automatically convert that to twenty years in your head. And on your client proposal.
This powerful estimation technique, among others, is explained more completely in the recorded talk, Managing Expectations: A Manager’s Guide for Managing to Manage Unmanageable Teams Manageably.
Mr. Haase is a software process methodology and management consultant. He enjoys helping clients solve large corporate technology problems almost as much as he enjoys billing them for it.
