> -----Original Message-----
> From: [EMAIL PROTECTED] On Behalf Of Javilk
> Sent: Tuesday, November 17, 1998 10:58 PM
> Exactly what do you consider a "function point"?
It's a strange coincidence, but I just got down to this month's
Scientific American in my to-read stack, and there was an article
by Capers Jones on function points. It doesn't seem like a very
informative article to me, but I'm not the audience it was intended
for. Take a look; it might be online on the SciAm site.
It's hard to define it briefly. A function point is essentially
a single identifiable externally-visible action. In a browser,
"follow a link" and "display a message" might be FPs. That
probably raises more questions than it answers.
> ... (Small wonder Yourdon says 60 percent of the DP projects fail!)
Ed is an incurable optimist.
> ... I would also say that quality is not a function of the
> number of function points. A poorly designed system will need more
> function points than one that has been well designed.
FP count should be independent of the goodness of design; FP count
measures what it does, not how well. However,
> And as one develops
> the system, it is probably that additional function points will have to be
> added to "catch" the failures of other function points, distorting the
> design and bloating the function point and line counts.
In other words, design in fact ends up saying a lot about *what* the system
does as well as *how*. So true.
> Since programmer productivity is about 2,500 lines of code per month,
Over what population? We did some pretty extensive surveys in the early
days of the Ada effort, and got figures like 700 LoC/month for simple
systems and 100 or less for things like OSs, signal processing, fire
control.
You have no idea the extent to which the government wastes your money.
On the other hand, I once implemented a real-time kernel for the Navy
with one other guy; we were competing with a team of six from Univac,
using the same requirements specs and the same (extensive) suite of
correctness and throughput tests. We did 5000 LoC/mm; they did <800.
We had 3 bugs; they had over 200 when we gave up trying to get them
through the test suite. Their source code was three times as big as
ours and their executable image was twice as large.
> People who do something for an income are generally interested in the
> income, and "getting it out the door". People who do something because
> they enjoy it are interested in the craftsmanship of their own work, and
> tend to implement improvements as they see them without such high regards
> for deadlines.
I don't buy that; it's not all one or the other. I work for the income
because it lets me buy the toys and fat pipe to the net. I do good work
because it get me the next job as well as for its own sake. I bust a
gut to make my deadlines because I know that giving users a working system
as early as possible is the best thing you can do.
> So assuming Woodnose95 uses about average programmers, call it 5 on
> the scale; ... Linux (programmers) are probably between 8 and 10
I don't know, the small number of MS programmers I've known have been
very good. They've mostly been graduates of the CS program at Brown or
second-generation Brown -- kids taught by our kids who went off to teach
at MIT, UNH, Princeton, Washington U, etc. I don't think that MS has bad
programmers in general, I'd tend to put the blame more on their middle
management and on whatever group it is that decides what features to add
to new releases of their products. This latter group apparently has never
met a feature they didn't like.
Bob Munck
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
