You don’t need to look at the code to estimate

Back to The Facts and Fictions of Estimation

An estimate from a developer can be defined as:

Time required to implement a feature.

As nearly all features are implemented in an existing codebase, it can be more accurately defined as:

Time required to implement a feature in an existing codebase.

As strange as it may sound, developers will tend to give estimates for building features in an existing codebase, without looking at that codebase. This seemingly illogical approach has several potential explanations:

  • The developer does not have the time or patience to identify all of the areas of code that will need to be modified in order to implement the feature.
  • The developer believes that an estimate is closer to a guess, than an educated approximation.
  • The developer thinks they know the work required, based on assumptions they have made about the codebase.
  • The developer is afraid of what they will find if they actually look at the codebase, and would prefer to defer that shock as long as possible.
  • The developer does not know where to look, due to inexperience with the codebase.
  • The developer lacks the experience to know that looking at the codebase before giving an estimate is a best practice.

There is an economy-of-time fallacy where developers believe that since the goal of an estimate is to assess time required, and doing a codebase assessment takes time, the total time required to implement a feature is reduced if no time is spent researching the estimate. For a trivial feature in a well-understood part of the codebase, this may very well be true. For a non-trivial feature in a lesser or unknown part of the codebase, the difference in a guessed vs. researched estimate can be dramatic. I have seen differences of days or even weeks, after I have asked a developer to look at the codebase to refine their original estimate.

All things be equal, I would prefer to not get an estimate from a developer, rather than get an estimate based on nothing but assumptions, fear, inexperience, or a lack of patience. Fortunately, this situation is entirely correctable: give the developer time to look in the codebase before demanding an estimate.