[lug] Developer abuse

[Paul E Condon]

On Fri, Nov 12, 2004 at 05:07:06PM -0700, Evelyn Mitchell wrote:
> * 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.
> 

In building construction, the estimate involves things like how many
nails must be driven and how long it takes to place one nail and to
drive it. These do change over time, but not by orders of
magnitude. Air powered nail drivers become popular after it has been
proved that the increase rate of nail driving by a single worker pays
for the cost of the nail gun in a suitably sort time.  So, even on the
first job where nail guns are used, the contractor has a good idea as
to how much they will speed up the work.

In software development, there is not really an analogous
situation. In software, if some task is can be seen to be repeated
many times, it can be automated by building a software generator. This
breaks the rules of estimation, namely that on this job one will do
the work as it was done on the last job. But the building of each new
generator is a task that has never been done before, and is therefore
difficult to estimate.

Software generators, as used in the above, include such tools as
compilers and linkage editors, which are taken as given by most, but
also includes specialized tools that are applicable to only a small
range of jobs. When, business strategists latch onto a particular new
way to use computers in business, there is a short period of time
during software developers do the same thing often enough to get some
idea as to how much time it takes, but this period alwas ends quickly.
Either business strategists lose interest in that use, or computer
developers write a genertor for that application type. Usually both
happen. The businessman is aware of the generator that is just about
to become available (vaporware) and expects to get his job done for
less than his competitor who has already paid for an earlier
version. And, the developer/consultant is also hopeful that the
vaporware will work for him.

A few decades ago, the design of electric motors was a skilled art
and there were only a few dozen people in the whole world who were
capable of doing it. Now, it is a computer program. 

The flip side is that some real world problems, such as machine
translation of natural language, do not have a satisfactory solution
even though a very great deal of effort has been expended on them.

I don't have the answer and I seriously doubt the claims of anyone
who says they do.

-- 
Paul E Condon           
pecondon at mesanetworks.net