[lug] Developer abuse

[Evelyn Mitchell]

* On 2004-11-12 13:24 Bill Thoen <bthoen at gisnet.com> 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.

I suspect the difficulty with estimation is the result of a whole
collection of factors, from the customer's need to have a go/no go estimate
before any work is done (which may be much easier to do in some fields of
work than others... construction comes to mind) to the flexibility of
software (can you change that.. yes), to the one-of-ness of a lot of
software development (it's less like building construction than scientific
research or management consulting).

One of the biggest factors, I believe, is just the pace of change in the
industry. In building construction, the estimator is working with a set of
processeses and materials which change on the order of a few percent per
year. Styles change, but the basic way things get done is pretty stable.

In software development, though, all of the components of the environment,
from the software tools (languages and libraries) to operating systems,
computer hardware performance and customer expectations are in flux, with
changes of >50%/year not uncommon.

So, something you did last year is not going to resemble what you need to
do this year very much, except in broad strokes. And even with a lot of
experience in the core skills, the problems keep getting more complex
because the opportunities are wider and expectations are higher.

If you never do anything more than twice (at the most), how are you
supposed to learn what your most likely performance is going to be, or your
range of likely performances?

One of the strengths of agile and XP is that they give developers and
customers small chunks of tasks, done with similar tools, with a similar
team on the same problem so they are able to refine their estimates over
time. If you're working on an 18 release project, that's a whole lot more
data to learn from then if you have a 2 release project.

But, and this is a big but, that still doesn't give the customer that
go/no-go number at the right stage of the project (at the beginning). 
As a businessperson, I know that I need to know whether or not a
development project makes monetary sense before I commit to it. 

I'd appreciate some discussion of this. As you can probably tell, this is a
problem I've been pondering for a while.

-- 
Regards,                    tummy.com, ltd 
Evelyn Mitchell             Linux Consulting since 1995
efm at tummy.com               Senior System and Network Administrators
                            http://www.tummy.com/