Software estimation is the ancient art of guessing how long something will take, saying it out loud, and being held to it like a vow at a wedding you didn’t want to attend. Project managers: print this table. Developers: you already know. You’ve always known.
The Conversion Table
- “Five minutes.” One afternoon. They have done this before. They have forgotten how, along with most of their twenties.
- “A couple of hours.” Two days. One for the work. One for everything the work broke.
- “Should be quick.” It will not be quick. “Should” is a wish, and wishes don’t ship.
- “End of the week.” End of next week. Weeks, to a developer, are rumours.
- “A sprint.” Two sprints and a retrospective nobody learns from.
- “It depends.” They have no idea. This is honesty. It will be punished.
- “Easy.” Danger. Said only about problems they haven’t opened. The ones they’ve opened, they don’t say anything about. They just go quiet.
All estimates are correct. They’re just correct for a much simpler project, run by a happier person, in a world that doesn’t exist.
Modifiers
Apply the following multipliers to any estimate:
- Client involved: x2
- Involves dates, time zones or currencies: x3
- Involves a printer: x infinity, cancel the project, cancel the company
- Developer said “I’ll just refactor it quickly while I’m in there”: add a month and a small memorial service
- Legacy code written by “someone who left”: write your will
Why Estimates Are Always Wrong
Because the only way to know how long something takes is to do it, at which point the estimate is a historical document. Estimation is predicting the weather by staring at a cloud, except the cloud is JavaScript and Sales has already sold the client sunshine and a bonus.
A Note for Developers
When asked for an estimate, think of a number. Double it. Add a week. Say it confidently. Watch the PM halve it in front of the client. Remember this moment on Saturday, at your desk, while your family has a nice time somewhere without you.