«
»

A Thing I Can Estimate

22nd January 2013, 05:00 pm

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.

Have fun.

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:

Category: Boring Story, Estimating, No Estimating  |  Comment (RSS)  |  Trackback

8 Comments

  1. Lance Walton:

    Let us suppose you have to drive somewhere new. Somewhere you haven’t driven before.

    Am I correct in thinking that you look at a map to understand what roads to take, or use a sat-nav or whatever, but otherwise you just get in your car and start driving, hoping you won’t get there late or way too early?

    23 January 2013, 3:20 pm

  2. Woody Z.:

    Hello Lance,

    I can easily estimate how long it will take to get to any location using maps, information about speed limits, information about construction, gas stations, traffic paterns, type of vehicle, purpose, and so on. That is my point: Car drives are easy to calculate. However, for a drive I’ve never done before I’ll generally have less confidence in my estimate because there are a lot of unknowns. Therefore I’ll need a larger arrival “window”.

    Cheers – Woody

    23 January 2013, 5:08 pm

  3. Lance Walton:

    Yes. Precisely.

    24 January 2013, 12:51 am

  4. Ron de Frates:

    Amen to that. Estimates for complex projects (i.e. software) are risky by nature. You either lose money if you underestimate or lose your client when you over-estimate. You can even lose your client to an unethical or inexperienced competitor who under-bids then makes it up with change-orders.

    That said it is possible to have a ‘win-win’ with estimates if your average bid across multiple projects is close to the actually number. This is much easier to achieve than getting it right every time. Of course, your range has to be reasonable for each project and it helps to have a good relationship to the client (i.e. trust and credibility). I’ve found breaking-up projects into smaller parts is useful also.

    It’s not ideal and not a replacement for solid Agile practices but it helps when faced with a client who insists on fixed priced projects.

    Great article! Thanks!

    26 January 2013, 5:43 pm

  5. Woody Z.:

    Thanks for your comments Ron! I think you have a reasonable compromise with your “win-win” proposition. But you know me – I think there is a better way. When the day comes that I don’t believe there is some way to make things better, it will be the day they spread my ashes across the Sierra Nevada. I just hope I’m dead by then.

    26 January 2013, 6:57 pm

  6. #NoEstimates Part 1: Doing Scrum without estimates | neilkillick.com:

    […] A thing I can estimate – Woody Zuill […]

    30 January 2013, 10:39 pm

  7. Diane Zajac-Woodie:

    I love your honest, straight forward explanation! And I totally agree with your stance; I just have never seen this in practice. 🙁 My experience is that other issues, such as funding projects instead of teams, strict release schedules and reliance on external teams (because we lack complete cross-functional teams), make it very difficult to avoid guessing at timeframes. I especially struggle with providing alternatives to management that demand estimates to hold up their house of cards.

    Do you feel that estimates can be eliminated if other practices, such as cross-functional teams, are not in place? Would it be more productive to focus on improving those first?

    Thanks for the post! 🙂

    9 February 2013, 9:00 pm

  8. Woody Z.:

    Hello Diane –

    Well, first of all THANKS for your comments.

    There are many issues that block effective productivity. There are many ways to deal with “management” that insists on following harmful practices.
    – One is to become management yourself.
    – Another is to consistently be the “voice of reason” and build solid relationships, friendships, and trust.
    – Find ways to explore alternative ideas.
    – Introduce retrospectives or similar activities and help others learn how to investigate ways to improve.

    Do I feel estimates can be eliminated if other practices are not in place? Absolutely – I believe estimates are at best “waste”, and more commonly outright harmful to the development process. I don’t think it makes a difference what other specific practices are in place – but managing without estimates will require that you quickly adopt practices that fulfill the Agile Values and Principles. However, I would imagine that for most orgs it might be better to focus on building the capabilities and setting up an environment where estimates become less and less important. I’ve found that if we can quickly get some part of a feature into code, built, ready to deploy, and demonstrated to the “stakeholders” the converstation about estimates is much easier to have.

    Cheers,
    Woody

    9 March 2013, 1:26 pm

Leave a comment