Estimate of hours to be spent on a project

  • Thread starter Thread starter Bob
  • Start date Start date
Hi Phlip,
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.
Click to expand...


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
 
Nick said:
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!
Click to expand...

Building a house depends on millenia of experience. Building the house is
the construction phase - the equivalent of one source rebuild.

Software Engineers use a 50-year old discipline to _design_ things.
Designing is really really hard.

Imagine if you get your architect's degree, and then get transported to a
moon at the Lagrange point between a gas giant and its giant moon. Your new
alien customers request a domicile made of gelatine, located on a plot of
land that experiences daily and seasonal tides up to 0.25 g.

You must begin all of your experiments over from scratch. Also, maybe the
aliens _want_ a house whose back walls stretch up every evening, and whose
front walls stretch up every morning. Or maybe not. You have no idea how to
predict anything in this process. The best alternative is to let the aliens
participate in scheduling the experiments and analyzing their results.
(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).
Click to expand...

It would have helped if Galileo had not written a deliberately inflamatory
book putting all the Pope's words in the mouth of a character named
"Simplicitous".
 
Bob said:
I have recently joined a healthcare company where I am the solo
programmer. I am going to be starting work on a project. The
management has asked me to provide an estimate of hours I am going to
spend on the project.

How do I estimate the number of hours I am going to spend on
programming in a project?
Click to expand...
Look at it and guess. A fast programmer is about ten times more productive
than a slow (but competent and employable) programmer, so any estimate
depends largely on your own ability.

The project sounds like it's a fairly routine "bash out the code" job where
there are no real technical problems to solve. The main thing that matters
is the quality of the spec, and the facilities you have for testing. What
very often happens is that managers demand to see a "prototype" (by which
they mean "the completed program", but can't get) and then ask for changes
based on the prototype. This is likely to increase development time
significantly, just as if you start building a road bridge and then are told
to run a railway over it as well.

Don't fall into the trap of breaking the problem into parts, and then
assigning a time to each one. This isn't where the time is likely to be
spent. Instead you will probably spend at least half the development time in
"integration testing", especially if the specification is wrong. This is why
good facilities for testing are so vital. Exactly how you would do it
depends on the nature of the program, but a dedicated tester is a good idea
for anything involving an extensive user interface. For batch type programs
you need "test data", and preferably different types of it so you can test
the program at different stages of development.
 
I've enjoyed debating with you Phlip. I hope to see more of your creative
and colorful allusions on the newsgroups in the future.

Cheers,
--- Nick

Imagine if you get your architect's degree, and then get transported to a
moon at the Lagrange point between a gas giant and its giant moon. Your new
alien customers request a domicile made of gelatine, located on a plot of
land that experiences daily and seasonal tides up to 0.25 g.

You must begin all of your experiments over from scratch. Also, maybe the
aliens _want_ a house whose back walls stretch up every evening, and whose
front walls stretch up every morning. Or maybe not.
Click to expand...
</snip>
 
Malcolm said:
Look at it and guess. A fast programmer is about ten times more productive
than a slow (but competent and employable) programmer, so any estimate
depends largely on your own ability.
Click to expand...

This was presented as (mostly) a joke, but there is a grain of truth to
it: It's the Law Of The Next Unit. Whatever N of Units you guess it
will take, leave N along and bump the Units.

If you think it'll take 3 hours, it'll take 3 days.
If you think it'll take 3 days, it'll take 3 weeks.
3 Weeks? No, 3 months.
3 Months? No, 3 years.

As I said, it was presented tongue in cheek, but having seen "trivial"
projects take way longer than I expected (particularly in a business
setting with a lot of interruptions, meetings and distractions), I can
testify to the grain of truth.
 
Bob said:
I have recently joined a healthcare company where I am the solo
programmer. I am going to be starting work on a project. The
management has asked me to provide an estimate of hours I am going to
spend on the project.

How do I estimate the number of hours I am going to spend on
programming in a project?
Click to expand...

You need to cover your ass and overestimate. A project coming in early
is good for everyone, while a project coming in late is much more of a
problem.

You should break down the project into as many small parts as possible.
Just keep on subdividing, and your picture will become clearer and
clearer. Make estimates of best-case, average-case, and nightmare-case
time for each part. Add each up. The actual time will be between the
average- and nightmare- totals.

This process extends into teams. Google for Gantt charts. If you keep
a detailed Gantt chart, you will know when you are ahead or behind.

HTH, Calum
 
You need to cover your ass and overestimate. A project coming in early
is good for everyone, while a project coming in late is much more of a
problem.
Click to expand...

That is true, but if you intend to last long in a job and have your
management chain respect your claims about such things, you need to
be as close as possible, and hopefully have enough history of getting
it right that they'll believe you when you say you need twice as long
as they guessed it would take. If you always overestimate, they'll
soon find out it's time to start chopping your schedule for you.
You should break down the project into as many small parts as possible.
Click to expand...

I disagree, but it depends upon experience. I read a 5 page spec today
and tell you within a week how long it will take to build. 15-20 years
ago I would have been way off. Moral of the story is junior programmers
shouldn't even be asked to do this type of approximation work. If you
are, and you have never done it before, all you can hope for is overestimating
and not getting overrulled by pragmatic schedule requirements of your
management.
Just keep on subdividing, and your picture will become clearer and
clearer. Make estimates of best-case, average-case, and nightmare-case
time for each part. Add each up. The actual time will be between the
average- and nightmare- totals.
Click to expand...

Bleh. This is busywork, and simply takes time away from actually doing
the design work.
This process extends into teams. Google for Gantt charts. If you keep
a detailed Gantt chart, you will know when you are ahead or behind.
Click to expand...

You have definitely been in corporate hell for far too long. :-)
 
Hi,

Randy Howard said:
You have definitely been in corporate hell for far too long. :-)
Click to expand...

I've been following this interresting thread since the beginning and i now
wonder if all that i've been taught in my project managment courses was just
bullshit. I've recently graduated (1 year and a half ago) and all the
project managment courses we had were about writing requirements reports,
specification reports, architecture reports, gantt charts and so on... and
then, and only then, starting the actual implementation.

I'm currently working in a company where i am the only one in charge of the
software and i've been quite confused by the way everything worked here:
i've been asked to do a piece of software and that's it. At each meeting,
after a demo of what was already done, the requirements were modified
because the boss decided that finally we would need that instead of this,
that this feature was not needed anymore, that this one should work in
another way... I've not been asked to write any report whatsoever.

I though that it was because the project managment in this company was
flawed but after reading this thread, i'm beginning to think that it may be
the "normal" way of doing things. So what do more experienced people think
of that? Should i insist on having a more rational project managment or
should i just let things go as they are right now?

Thanks
Click to expand...
 
Elp said:
Hi,

Randy Howard said:
I've been following this interresting thread since the beginning and i now
Click to expand...

Me too. I'm amazed how many people have said 'estimate then multiply by
ten'. As far as I can tell, there's two main reasons for saying something
like that:

a) They're a junior developer and have yet to learn estimation, or
b) At that stage in the project they're trying to give a single number where
a range would be more useful.
wonder if all that i've been taught in my project managment courses was just
bullshit. I've recently graduated (1 year and a half ago) and all the
project managment courses we had were about writing requirements reports,
specification reports, architecture reports, gantt charts and so on... and
then, and only then, starting the actual implementation.
Click to expand...

Sounds like the waterfall model, which does sometimes have its uses, and
which is at the far end of the scale which starts at "muddle along, make up
estimates and multiply by ten". Somewhere in the middle is probably the
norm.
I'm currently working in a company where i am the only one in charge of the
software and i've been quite confused by the way everything worked here:
i've been asked to do a piece of software and that's it. At each meeting,
after a demo of what was already done, the requirements were modified
because the boss decided that finally we would need that instead of this,
that this feature was not needed anymore, that this one should work in
another way... I've not been asked to write any report whatsoever.

I though that it was because the project managment in this company was
flawed but after reading this thread, i'm beginning to think that it may be
the "normal" way of doing things. So what do more experienced people think
of that? Should i insist on having a more rational project managment or
should i just let things go as they are right now?
Click to expand...

That style of project progression isn't necessarily a bad thing. It can lead
to never-ending projects. It's fine provided the boss realises that you
won't be able to give him any estimate (since the 'design' is entirely in
his head).

Really it depends on the project. You have to match the process to the
project. You tend to get people telling you that 'such-and-such methodology'
is the only way to go, which leads to plenty of arguments but isn't very
helpful. Rather, it's better to be aware of many methodologies, and pick the
one which matches your project {size, deadline, 'criticality', management}.
Click to expand...
 
First off, ignore your college PM course. It is teaching you waterfall.
This model has been discredited.

Ignore all the advice about "break down your work into small tasks and
estimate the time for each". As Capers Jones has proven, they are wrong
nearly all the time. It would be better to throw darts to get an estimate.
(See my contribution to this thread on estimation).

Next, go out and buy one of the dozens of books on Agile software
development. It's harder to do when you are flying solo, but the practices
(especially some of the Test Driven Development and Planning Game practices,
will really help you).

My fav books on the subject (at present) are:
Extreme Programming Explained: Embrace Change by Kent Beck
Agile Project Management with Scrum by Ken Schwaber

I admit to bias on the last one...
--- Nick Malik
Certified Scrum Master

Elp said:
Hi,
Click to expand...
 
Back
Top