Always working estimation techniques - reference to past data

  • How long does it take to put all the dirty place into dishwasher?

  • How long does it take to do the regular weekend shopping?

  • How long does it take to got to work?

What is common in all of the examples that you could give quite accurate estimate about them. But it was not always true. You were not able to tell how long it takes to get to the school when you have just moved to the new town. You had to go a few times then you have collected enough real life experience to answer the question.

And the same can be applied to software projects.

How long did it take last time:

  • to implement new database query?

  • to create new form with a dozens of fields with input validation?

  • to implement new web controller (independently from technology stack - struts, struts2 or spring mvc)?

  • to set up a new development environment?

  • to set up a new server?

  • to implement customization of the core product to a new client?

For the first time the answer is always: "I do no know." But the second time you already have some reference you could use.

Each time we introduced our product to new client there were a need for certain customization. As development manager I was asked all the time how long it will take to customize the new client version? Most of the time this question is asked before knowing anything specific about their needs. But my estimation was always accurate because we did such a customization many times and I had my records. When I got this question I answered: "as long as it is taken for client X"

Why is it so powerful? When you have at least 5 past data (at task level or User story level it is not even a big number; in larger scale it might be problematic) you can be sure that any future data will fall into the range of min and max of these samples with 90% confidentiality.

Rule of Five

There is a 93.75% chance that the median of a population is between the smallest and largest values in any sample of five from that population.

How to measure anything
— Douglas W. Hubbard

Why is it not used more often?

  • no records about actual execution time

  • non-experienced developers either in business or technology

  • new technology

  • crappy code make estimates unpredictable

If you do not have historical record about your executions you should start collecting them. Many times you do not really need precise bookkeeping about time spent. I am sure that you are remembering how long certain thinks were taken in the past, at least approximately.

New developer is always an something unpredictable. If developer is beginner you should not count on him until he proved to be able to deliver reliably.

Uncle Bob in one of his interview or Clean Coders video were talking about why there are not so many old and experienced programmers. They are there but every year there are so many new, freshly "graduated" programmer that you could not recognize them. They made a quick estimate what is the approximate proportion of experienced developer available and they found that 80% of developers have less then 5 years of experience, worldwide.

What are you expecting from someone having less 5 years of experience in large scale? After how many years of experience can someone made brain surgery or build a bridge over a river, or just simply construct a family house without supervision? Hiring newbie developers is a risk you have to control. You have to invest into hiring more expensive but experienced developers. And do not forget the 10x effect of individual developers.

The lack of business knowledge can be controlled. It is not possible to have a whole development team without the business experience (of course it can be but in that case it is an extraordinary bad management decision). In this case experienced developer is responsible for estimation. Of course, a business training is always needed too. If none of these solutions are working you must pay a big money to hire developer with the relevant business experience. Then you could return to the first solution.

New technology. Hmmm… Do you really need to introduce new technology? As an example. Nowadays the so called Big Data problems triggering the use of so called NoSQL databases. But as I see most of the business does not have big data problem. Most of the business has simple database and SQL tuning problems.

If you say that new technology is a must then the solution is the same as described in the previous paragraphs: experienced one is responsible for the estimates of the less experienced one; training; hire the master of technology.

Crappy code: Sucker. I do not know how to deal with it effectively. This is not a problem when brand new code is written because it does not exists yet. But when you are altering existing shit around you…. From professional point of view I know how to improve the quality of shitty code but I do not know how to bypass unreliable estimates it is causing.


Management stack
Mar 13, 2015
comments powered by Disqus

Links

Cool

RSS