This post is a review for a excellent post series written by Jacob Kaplan-Moss, here the link to the series: Series: Estimating Software Projects
Why want to learn effort estimation?
One major “secret” to advancing in a technical career is learning how to give accurate estimates.
And I don't want to let my boss down again...
Techique for capturing both time and uncertainty:
- Break down work into less-complex tasks
- Estimate uncertainty
- Do the math to get expected- and worst-case estimates
- Refine, if needed
- Track your accuracy, so you can improve over time
Complexity
Can list the complexity as size and corresponding time:
| Complexity | Time |
|---|---|
| small | 1 day |
| medium | 3 days |
| large | 1 week (5 days) |
| extra-large | 2 weeks (10 days) |
Uncertainty
uncertainty system starts with the expected time (captured above), and then applies an “if-things-go-wrong” multiplier:
| Uncertainty Level | Multiplier |
|---|---|
| low | 1.1 |
| moderate | 1.5 |
| high | 2.0 |
| extreme | 5.0 |
Complexity + Uncertainty = Estimation
Combind complexity and uncertainty, we got the table as:
| Task | Complexity | Uncertainty | Expected | Worst-case |
|---|---|---|---|---|
| Refactor the doodad | small | low | 1 day | 1.1 days |
| Swizzle columns | large | moderate | 5 days | 7.5 days |
| Reticulate splines | medium | extreme | 5 days | 25 days |
| Reverse manifold intake | medium | medium | 3 days | 4.5 days |
| Deploy | small | low | 1 days | 1.1 days |
| Total: | 15 days | 39 days |
I think this is the first version that can be presented to bosses.
In the far left column, we can further divide the task into many small tasks.
Refine and clean up uncertainty
Three techniques:
- Research: Easy to understand, do research to know how far we need to go.
- Spikes: Feel like a quick prototype. Author wrote: "The idea is that you spend a bit of time exploring a potential solution, usually by diving in and writing some software. Sometimes the spike ends up becoming part of your project, but more often it’s throw-away code designed to just prove a point."
- JFDI: Just Fucking Do It. Give yourself or your team a week or two, and dive in.
Quote: The key observation is that, if you’re dealing with a too-uncertain estimate, or one that needs to be broken down further, you can trade some time up-front for a better estimate.
The above text is copied from the original post. I really like the sentence "trade some time up-front for a better estimate".
Not just giving estimate, in any negotiation that feeling uncomfortable to give an answer, should find a way to buy more time.
Track your accuracy
Author added a far right column for tracking the actual progress with Expected and Worst-case:
| Task | Complexity | Uncertainty | Expected | Worst-case | Actual |
|---|---|---|---|---|---|
| Refactor the doodad | small | low | 1 day | 1.1 days | 2 days |
| Swizzle columns | large | moderate | 5 days | 7.5 days | 3 days |
| Reticulate splines | medium | extreme | 5 days | 25 days | 10 days |
| Reverse manifold intake | medium | medium | 3 days | 4.5 days | 3 days |
| Deploy | low | low | 1 days | 1.1 days | 3 days |
Quote: This is why, although the specific complexity and uncertainty sizes are fairly arbitrary, it’s important to choose a model and stick with it. If you re-define what
`low`means, you’ll need to start over and recalibrate all future estimates.
Wow, the final sentence is so TRUE! The estimation should be a model that keeps evolving, not the one we throw away after it is sent to your boss.
How to give a quick estimation(SWAG)
Sometimes your boss would ask you randomly in a meeting how long it will take to train a LLM (just kidding).
Which means you don't have time like we did above to give a rough one first and refine later.
Quote: You can make a Simple Wild-Ass Guess – a SWAG. You never have to make a SWAG – it’s always appropriate to defer until you’ve had time to make a proper estimate.
Iron Triangle constraints
- Fixed Timeline
- Fixed Budget
- Non-negotiable Quality
I guess this is also the 3 pillars of manging a project. Iron triangle means you can't change any of the pillars, which basically means you have to be perfect to compelete the project.
But in reality, we usually need to change one or two of the 3 pillars.
How to give SWAG
If you have to give a SWAG, make sure give the answer in orders of magnitude – “days”, “weeks”, “months”, or “quarters”.
If you are not sure, should also deliberately sound vague and squishy.
If it's important to give the estimation, you should have a catch-up meeting to give the estimation.
Again, there feels like buying time for estimation.
Avoid messing up
You have all kinds of techniques, but you will still mess up the project.
The author told the reason why he left Heroku in this post: https://jacobian.org/2021/jun/8/incorrect-estimates/.
Don't communicate lateness too late
Engaging in magical thinking as a defense mechanism against the reality that something has been wrong is the major reason that led to the one of the biggest failure in author's career.
A way to fight back against this is to report status frequently – weekly, probably. Some organizations have regularly established mechanisms for status.
Or send weekly status emails to your boss. It's the same thing.
The idea here is finding a way to force yourself to avoid being trapped in magical thinking.
Avoid magical thinking
I like the story about peope who are lost get event more lost.
The "bending the map" phenomenon reminds me doing a software project is somewhat like leading a team getting through a jungle.
Some crucial facts to help you stay awake:
- Late projects stay late. Rarely you can catch up on a late project.
- Late project usually get later.
- Adding more people to a late project makes it later
- “Crunch time” *can* work, but only sparingly and at a high cost: This means working overtime to catch up. If it's only you working on the project, it's fine. If it's a team, the author wrote: Teams can only sustain crunch time for a week or two at most before quality suffers dramatically.
Make a new estimate (but keep the old one)
As soon as you realize you are late, create a new estimate.
Remember keep the old one for review. That is how you grow.
One more thing, giving estimate is a skill that needs practice.
Procedure
Now, let me try to come out a procedure based on the series.
- Understand the requirements of functionality.
- Roughly devide the requirements into chunks.
- mark each chunk with complexity.
- If there is too much uncertainty, do research or do spike prototype to get more precise estimate.
- If the chunk is a large or extra large, further divide it into smaller peices.
- Mark each chunk (or task) with uncertainty level and multiplier.
- Present the first version estimate to boss.
If your boss feel like it takes too long, then it's time to change the 3 pillars on iron triangle. E.g. reducing timeline needs either lower quality*(cut off some of the requirements)* or more budget*(add more people)*.
If your boss don't like any of this, then good luck to you, you are falling into the iron triangle situation!
Remember, when you feel uncomfortable, you need to find a way to buy more time for estimate. Usually, it's ok and not difficult to do so.
You will still screw up the plan
Even thought somewhat a weapon in the hand and somewhat have drawed a map throught the jungle.
Another interesting blog post keep reminding me: there are unknown ahead.
The link is My Washing Machine Refreshed My Thinking on Software Effort Estimation.
The author estimated a 10min washing machine installation but got 4 hours at the end due to the unexpected blockers.
The author listed all the blocks out, it's a very interesting story.
To further understand why estimation on software projects is so hard to be accurate, I found this great post: Is tasking developers with creating detailed estimates a waste of company money?.
The post summarizes what the washing machine story wants to tell very accurately :
Software development involves messy discovery of new tasks in the complex and abstract environment of code, which results in software development task durations being a "?".
The post also suggested a good way to estimate the cost:
Use historical information to guide your high level estimates for future projects. You've got a set of historical data on how many engineers you had working on various completed projects, right? Good! If not, spend some time and gather that information. Then sit down with your relevant Dev Managers and figure out what work in the upcoming project is similar to work completed in the past and use that as a guideline for predicting the future.
Conclusion
Finally, let's end this post.
We have a way to do estimation for software projects as a procedure came out based on the post series: Series: Estimating Software Projects.
But the story about installing washing machine reminds the unknown ahead, which is the uncertainty that remain unknown ahead.
This post told an important rule: use the estimations in the past as the guideline for the future. This reminds me to keep estimations made in the past.