Loading ...
Sorry, an error occurred while loading the content.

Ideal programming time (Was: Customer doesn't trust our estimates)

Expand Messages
  • Steve Bate
    ... Hi Kiel, If the word ideal is causing problems, you could think in terms of programming time instead. It doesn t seem difficult to understand that a
    Message 1 of 50 , Apr 1, 2003
      > From: Kiel Hodges [mailto:kielhodges@...]
      > I have an unproven hypothesis: thinking in terms of ideal days is
      > misleading for everybody, not just the customer. I think that
      > some developers keep chasing that ideal when they estimate. It's
      > kind of like the joke about doubling your estimates so that
      > they'll be 50% of the real value.

      Hi Kiel,

      If the word "ideal" is causing problems, you could think in terms
      of "programming time" instead. It doesn't seem difficult to
      understand that a given amount of programming time can take any
      amount of clock time. Think of a task that is started before you
      go on a vacation and then finished afterwards. The programming
      time for the task may have been a few hours (and is mostly
      independent of the vacation duration), but the clock time might
      be a week or two.

      > Forget about how much ideal programming time you can get done
      > during a day. It won't help you and it won't help your customer.

      Again, eliminating the "ideal" so that we are simply looking at
      programming time I have found this does help both myself and
      many of the my customers over the years. (I used programming
      time estimates even before I worked on XP projects.)

      > In particular, it won't lead to getting more done during a day.
      > That can only happen in two ways: by improving the code and
      > practices so that you can produce more functionality with less
      > effort, and by removing things that take away from productive
      > time. Ideal time has nothing to do with the former. Ideal time
      > won't identify those things in the latter.

      Although I agree it won't identify the causes of excessive overhead,
      programming time per day can be a strong hint as to whether overhead
      is even a problem or not. If a team is only able to program 2
      hours/day then overhead is definitely something to investigate. If
      they are programming 5-6+ hours/day then overhead may not be an
      issue and it might be more effective to focus on coding practices.

      There are factors in addition to the ones you mention that can
      affect productivity. They are more intangible but it's clear to me
      that motivation, interpersonal group dynamics, pride in the work
      being performed, and so on can significantly affect productivity.
      There are even seasonal differences. Speaking for myself, I'll
      generally work more hours when the weather is bad. Conversely,
      I'll find myself daydreaming more about mountain biking or hiking
      or sailing when the weather is good. I'm sure that must have
      some effect on my productivity. My point is that productivity is
      affected by many forces. Tracking programming time is just one
      tool for understanding current productivity and possible ways
      of increasing it.

      > I think ideal time is assumed by some to better that points
      > because is more "real". It's not. The hint is that word "ideal".
      > That implies "not real". What's worse than not knowing something?
      > Knowing something that isn't true!

      From what I've seen on this list, most people base their point
      estimates on programming time anyway (at least to determine their
      baseline "1 point" story estimate). From that perspective, it seems
      to me that points are one or two levels of indirection (baseline
      story plus integral multipliers) from programming time. I
      prefer to use the primary information. I'm not claiming it's
      better in any absolute sense but it works great for me.

    • davechaplin
      Is your customer technical? If so, then ask them to show you how they would do it quicker. Admit that you don t know. You know yourself that you are working
      Message 50 of 50 , Apr 9, 2003
        Is your customer technical? If so, then ask them to show you how they
        would do it quicker. Admit that you don't know. You know yourself
        that you are working very fast using XP, and that the quality
        investments you are making will pay off. You can gamble on that. Make
        sure your estimates accurate though, since no-one likes a deadline
        that isn't hit. Under promise /commit, and over deliver.

        Don't tell her you are coding 6 hours a day regardless. Tell her you
        are coding 8, then make sure you only code spikes and R&D stuff in
        the other 2 hours. Personally, we stop touching production code after
        about 4pm. Our brains are a bit dead. Then we work on previously
        marked TODO's/STUB's in the code that are low brain activities to fix.

        Regarding the problems with times estimates. Give a range if you are
        unsure. e.g. between 5 and 15 days. Tell her you need to do some R&D
        for 2 days to get an accurate estimate. If she takes the lower one
        that is her problem and you have a project management problem you
        need to solve. Openly refuse to commit to deadlines unless you are
        sure of hitting them. I suspect you had project overuns in the past
        because someone else other than the developers was promising
        something that couldn't be delivered. Seen that before. It was solved
        by the particular project manager being marched out the building by
        security. That solved it!

        Hope that helps.


        --- In extremeprogramming@yahoogroups.com, "rodriguez_jose48"
        <rodriguez_jose48@y...> wrote:
        > Now, after we've managed to have some separation of
        > between programmers and Customer, our main problem is that the
        > customer does not trust our estimates.
        > She thinks we are giving her too big estimates, and that we are
        > working too slowly. She is right in thinking like this because in
        > past this project didn't went so well, and schedule overruns were
        > a 'normal' thing.
        > What can we do to solve this problem?
        > This has a couple of bad consequences over the process.
        > For example we cannot tell her we are programming only 5-6
        > I've seen on this list that others have a similar period of
        > coding each day, so I believe it is a normal thing (anyway we are
        > tired after 5-6 hours of effective coding).
        > Another problem is that we fear to have the Customer with us during
        > the planning. We fear that we will not be able to give an accurate
        > estimate in a short time (planning a story shouldn't take long, I
        > guess) and if we give a shorter estimate, she will not agree to
        > change it in the future.
        > Besides, during the planning game, we, the programmers, have to be
        > careful, not to tell anything about the mapping real time/ideal
        > (we are estimating in ideal days and weeks).
        > Any ideas?
        > Jose.
      Your message has been successfully submitted and would be delivered to recipients shortly.