[lug] Developer abuse

[David Morris]

On Fri, Nov 12, 2004 at 01:37:39PM -0700, Bill Thoen wrote:
> How come software projects seem to be so hard to estimate
> correctly? Civil engineers have standard practices and
> procedures and when they build a 20-story building, they
> generally know how much it's going to cost and when it
> will be done -- in advance of the first brick being laid
> upon another -- and also they are relatively sure that if
> some 14-year old kid sneaks in the back door some day that
> he isn't going to be able to drop the building like a
> house of cards by pushing the elevator buttons in an
> unexpected order.

The simple truth is that estimating cost and schedule for a
software project is NOT any harder than for a construction
project....IF you treat it the same way the civil engineer
does.  It takes careful planning, detailed knowledge
regarding how long it takes to complete tasks, lots of work,
and clearly defined requirements.

The problem comes in when the requirements and design are
not properly researched or when the initial plan is not
created based on realistic metrics (e.g. how many lines of
code a developer writes per hour, how long it takes to run
tests, how long it takes to review designs, etc.).  The
numbers on how long it takes to complete a given task are
every bit as well known as numbers for construction, such as
how long it takes to put in a nail using a nail-gun.
Software development as a whole has such numbers available
and each industry has more refined numbers.  Any company
with even a tiny amount of common sense refines the industry
numbers even further based on their on process.

There is also a VERY bad assumption by most people that
software is easily changeable and that if any problems
arrise you can simply change the software.

This is simply wrong.

If new requirements are found after the design is complete
it will effect cost and schedule, just like such a new
requirements will effect the cost and schedule of a building
construction project.  If the design is not properly laid
out you will again effect cost and schedule when it breaks
down, just like in a construction project.  And on and on
through all areas of the software project.

I work on a software project (25 people on the software team
when we were at full-tilt) that was done properly and we
have so far met every milestone under-budget and ahead of
schedule.  Note that the project began over 2.5 years ago
and will not end for approximately another year.

How did we manage to do this?  Our manager carefully planned
every stage of the project in detail.  Requirements were
researched and finalized before the design process began.
The system-level design was finished before any coding
began.  At a unit level (the system is broken into about 30
smaller units), the design was again finished before the
coding began.

No requirements change without a VERY good reason.  No
design changes unless it doesn't meet the requirements.

Now, the project hasn't gone completely smoothly because the
overall project (building the payload for a sattelite) ran
into some fundamental hardware problems and the customer (we
are a contractor) ran out of money for a short bit, but
those were items outside of the software group's control.
At each stage we had problems, new planning took place to
determine what changes needed to be made and we continued to
meet the new milestones.

It isn't that difficult, most projects simply don't put in
the effort to do the job right the way a Civil Engineer
does.

--David