This is a post about a trivial thing that I can estimate, and there is a non-trivial point I want to make at the end. So you can just skip-to-the-end if that is the sort of person you are.
I can estimate how long it will take me to drive to work.
I drive to work 5 days a week. I need to get to my workplace, but I also want to pick up my daily oatmeal and drink for breakfast at a fast-food drive-thru. Simple stuff.
Why do I need an estimate?
I need an estimate so I can be sure to leave home early enough to get to work on time.
I like to get to work 15 minutes early, and I’d like to make sure that I am never late except in exceptional cases. So if I can estimate a time that will get me there about 15 minutes early, but never later than 5 minutes early that would work for me. I don’t mind if I am 20 minutes early, but I don’t really want to be 25 minutes early. So, I’m looking for a time range that gets me to work between 7:40 and 7:55, with the ideal spot being 7:45.
I want to be on time to work, with sufficient time to not worry about being late, and still not waste too much time just sitting there tweeting about estimates.
I drive pretty much the same route every day with about 10 minor alternatives available. I can take advantage of these alternatives (turn right here, or turn right a block up, stop at this fast-food or at that fast-food, etc) to make allowances for congestion at traffic lights, schools (school days are busy, holidays are not), drive-thru lines, and stuff like that – so I make a lot of little decisions on the way. For example: I’ll turn right at a light if there are a lot of cars backed up and take a chance that the next street isn’t backed up. That allows me adjust to get a better chance at a good drive time.
I can estimate how long this will take, and use that estimate most of the time.
Yesterday it took 40 minutes, the day before 43 minutes, the day before that 36 minutes (school holiday). Over the last year, I’ve found that it takes about 40 minutes to drive to work on a typical day.
If I leave at 7:05, I will almost always get to work in my target time-frame.
All well and good. And that works great for me for typical days.
I can take advantage of daily changes
I “re-estimate” daily to adjust for school holidays, weather, etc. and vary the time I leave for work to compensate.
To clarify: I re-estimate every day to adjust for daily differences. I can “re-estimate” quickly. The cost is about 10 seconds of my time.
On a school holiday, I can sleep in 5 minutes. If it is raining, I must leave 10 minutes early. If it is snowing, something is really wrong because it never snows here.
Why Does This Work?
You already know:
- I have a lot of data – way more than is needed.
- I know all the variables (weather/holiday/etc)
- I know the work-arounds (alternative routes)
- It’s essentially the same thing every day
- There are almost no unknowns
- There is almost nothing new to learn
- I can trust the guy who is providing the numbers. It’s me.
That is, it is trivial.
By the way - I can’t control the variables to predict an exact time, so a range is sufficient.
Having the estimate is useful as it helps me optimize my sleep time and still reach work on time.
This is the Non Trivial Part: How Similar Is This To Computer Programming?
So, if it is useful to have an estimate, and we can make a meaningful estimate – then we have a good application of estimates. That is the case with my “drive to work” example.
In my humble opinion, this is not similar to computer programming. We have the first part: We feel estimates would be useful, but we don’t have the second part – the estimates are not meaningful unless you are doing very trivial work.
With software development we don’t have much data, we don’t know the variables, we don’t know the work-arounds, each project is very different, there are lots of unknowns, there is much to learn, and I can’t trust anyone for “good numbers”, not even ME. By the time we know enough about what we are doing to make useful estimates they are useless because we are DONE.
When we find our software development work is “easy to estimate” it is likely that it is trivial in nature. That is, if it matches the nature of my “drive to work” example then I would question if that work is actually software development. In software development, when I find I am doing the same thing over and over, know all the variables, have few unknowns, have little to learn – then that’s the time I investigate ways to automate it and stop “programming” it.
And remember: This is ALL JUST MY OPINION. Don’t do anything I say. Don’t mention to anyone else that this makes sense to you, they will just say you are crazy.
Some other posts I’ve written on the topic of estimating:
- Estimation is Easy and Useful: Estimate a game of Chess
- Do Estimates Do What We Want Them To Do?
- No Estimate Programming Series – Intro Post
- No Estimate Approach For End-Of-Life Legacy Support
- Notes From A Conference Session On No Estimates in Software Development
- A Comment And Response from Estimate Chess Post
- Can We Code Without Estimates?