Re: Estimate of hours to be spent on a project

• Previous message: Beringer: "Default Value of ComboBoxes..."
• In reply to: Phlip: "Re: Estimate of hours to be spent on a project"
• Next in thread: Phlip: "Re: Estimate of hours to be spent on a project"
• Reply: Phlip: "Re: Estimate of hours to be spent on a project"
• Messages sorted by: [ date ] [ thread ]

Date: Sun, 11 Jul 2004 08:29:41 GMT

Hi Phlip,

> > The question is: "I'm deciding between 10 different priorities for my
> budget
> > for next year. I have a one-page description of each problem. How much
> > will each one cost, and how many resources will each one take?"
>
> No prob. You request the difference between selecting a direction and
> targetting a destination.
>
> Directions are safe to select up-front, and to schedule and budget
> proactively. Destinations (such as Features A thru N before the Trade Show
> in September) cannot be scheduled and budgetted up front. The features
> require tracking.

I appreciate the distinction.
In the planning game, it is not only reasonable to approach a problem from
the standpoint of what you know but also to recognize that there are some
things that cannot be accurately known.

This makes sense.

However, the business users don't care.

Think about it. If you ask an architect "how much will it cost to build my
house," and he gives an answer, he will be CLOSE. He or she will set
expectations that there are unknown things that occur, and changes can be
made at many points. However, an architect building a house, or an engineer
designing a supporting structure, is still required to give an accurate
estimate. This is not a "direction". This is a very specific destination,
with specific features, specific resources, a specific timeline, and a
reasonable estimate of how far off the estimate is likely to be.

These questions can be answered by science. The techniques can be learned
by engineering. Unfortunately, in Computer Science, we largely ignore the
Science. We, as an industry, do a lousy job of creating a hypothesis and
actually TESTING it to see if it works. That's why Waterfall models are so
prevalent. They make sense... who care if they are wrong!

(It makes sense that a cannon ball should fall faster than a wooden ball,
but they don't. Everyone assumed that they did... until a simple scientific
experiment proved them wrong. To thank the scientist, the Catholic church
convicted Galileo of heresy and convicted him to life under house arrest).

We are still preaching Aristotle vs. Copernicus! More importantly, we are
still preaching!

If you want to know how much something costs to build, look at how much the
last one cost to build. Experiments and measurement tell us: The variations
are NOT the people... the variations are in the system. Science can prove
this, and has. You CAN give a good answer to the question, without
betraying the principles of good design. BE LIKE THE ARCHITECT. He is not
sacrificing good design to answer a simple, and essential, question.

The answer can be given because productivity has been measured, and it
continues to be measured, by a veritable army of software metrics
specialists who practice in utter obscurity to measure and document the size
of systems and the time that they took to build.

To use these numbers, you simply measure the system you are trying to build
(the requirements do not have to be completely known... but the farther you
are from knowing them, the less reliable your estimates are. The architect
would say the same thing). You can measure the size of a system,
independently of the technology, by measuring the requirements. You take
the size (your measurement), multiply by expected productivity (using
national numbers and ranges) and you reach a reasonable estimate.

It takes training, true, but I have faith that you could learn it, if you
tried.

It is called Function Point Analysis. (see www.ifpug.org)

It works in the agile world. (It has Nothing to do with How the software is
developed... it has only to do with the cost of developing it). It also
works in the predictive MDA world.

It works well.

So the next time someone says a "cost estimation" is the same as a
"selecting a direction," realize that there are folks, like me, who would
find that statement humorous, if it was not so dogmatic.

I've sat on the business side. Business people are NOT WRONG to require
this information.

You can give it to them... if you are willing to embrace change.

With utmost respect,
--- Nick Malik
     Certified Scrum Master
     Certified Function Point Specialist

• Previous message: Beringer: "Default Value of ComboBoxes..."
• In reply to: Phlip: "Re: Estimate of hours to be spent on a project"
• Next in thread: Phlip: "Re: Estimate of hours to be spent on a project"
• Reply: Phlip: "Re: Estimate of hours to be spent on a project"
• Messages sorted by: [ date ] [ thread ]