NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/software/4479

Internet Message Format | 1992-11-23 | 4.2 KB

Path: sparky!uunet!olivea!charnel!sifon!homer.cs.mcgill.ca!zaphod
From: [e-mail] (Morris BERNSTEIN)
Newsgroups: comp.software-eng
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
Message-ID: <[e-mail]>
Date: 23 Nov 92 22:22:50 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (Netnews Administrator)
Organization: SOCS - Mcgill University, Montreal, Canada
Lines: 85

In article <[e-mail]> [e-mail] (Scott Mcgregor) writes:
>Sometimes I am not so sure about software companies.  They sometimes
>seem to put resources on projects that will only make money if they
>meet a tight market window and have high initial demand.  They might
>be better off skipping those projects and working on some less
>demanding ones occassionally.

The problem is that (in my experience) most projects tend to have that
pressure.  Time and time again, I've seen that the project is given to
the one with the best promises rather than the one with the most
realistic schedule.


>                They decline to give any estimate, rather than choose
>one and have a variance when the actual is measured. This reluctance
>to deal with anything that isn't purely deterministic and calculable
>makes the software industry different from many others.

There's another problem that I've come across.  If I'm going to make a
reasonable estimate, I need to have some information about what the
customer wants.  Ideally, we should be able to say to the customer,
"tell us what you want and we'll give you a product spec in X weeks".
Once the product spec is delivered, we set a date for the design
document.  Once we've done the design, then we have some reasonable
idea how much development effort is required.

In practice, the customer says, "we're not sure what we want, but the
system must be delivered in a year, so set the dates for the gates
accordingly".  Six months into the development cycle, the customer
comes back and says, "We also need these additional features.  Late?
What do you mean late?"

>...
>"Oh let's see, there's a guy standing next to the bridge there, let's
>assume he's about 5 feet for easy arithmetic. if he laid down he'd
>extend about half way between those two struts so they'd be about 10
>feet apart. Theres one, two, three---ten of them. So the bridge is
>about 100 feet long, with ten major struts, based on past experience
>maybe 6-18 months to design and build."

Yeah, the civil engineer has built a brigde before.  With software,
especially with reuse, each new application is *different* from the
previous.  Sure, I can tell you how long it would take me to write a
dictionary data structure, but how do I decide a priori that I need
the dictionary and not some other structure?


...
>"So it will probably take between a month and a year?"
>
>"Yes, definately. But I can't tell you when exactly."
>
>"So you just gave me an estimate. If I can make sure we can make a
>profit, even if the project runs a year, then I can be sure that this
>is a good thing to do.  If it is only profitable if it takes less than
>a year I'm taking a bigger risk, right?"
>
>"Sure.  But that's a pretty big variance. You don't really know how
>long it is really going to ta."
>
>"I don't need more accuracy.  I just need to know the possible
>variances, not just the mean. As long as you are within those, no
>matter how big they are, I can manage the risk and project go/no go
>decisions. I can manage risk/reward (profit requirements).  But if you
>don't give me any estimate I am hosed."
>
>"Oh, well that's not too hard then."
>
>"That's what I thought all along!"

Suppose you're looking for a contractor and you get three estimates:
    1) two months
    2) six months
    3) some time betweeen a month and a year
Who would you pick?

I am going to get better with my estimation abilities because I have
to, but how do I compete with someone who is willing to underbid me
and make the profit by cutting on things the customer can't
immediately see, like maintainability (and don't say that the customer
should know about these things because if they did, they wouldn't need
the contractor)?


Morris