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

Text File | 1992-11-16 | 3.5 KB | 84 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!usc!rpi!batcomputer!cornell!rochester!rocksanne!leisner
From: [e-mail] ( Marty Leisner)
Subject: Re: Will we keep ignoring this productivity issue?
Message-ID: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Xerox
X-Newsreader: TIN [version 1.1 PL6]
References: <[e-mail]>
Date: Mon, 16 Nov 1992 15:11:13 GMT
Lines: 70

Scott Mcgregor ([e-mail]) wrote:
: Chief Programming Teams and power:
:
: I think the idea that Chief Programming Teams gives one individual too much
: power for management's taste is only part of the situation. It makes
: you very vulnerable to a HUGE slip if that person leaves. ..

True, but it is a way to get conceptual integrity if you can find a
good chief programmer.

And the way around this is to have a chief-programmer in training understand
everything the chief programmer does, ready to step in if the chief-programmer
leaves.

When you put 15 hardware engineers in a room, they'll agree on a good
design and a bad design.

If you put 15 software engineers in a room, its unlikely you'll have
any agreement.

So you have a trust a chief programmer, unless you can **justify** a better
way...You often can't prove something until its completed...software is
far to abstract.

Writing software is like any type of writing...and great writers are rare.
If you have a team of people writing chapters of a book, it will be hard to
read.

In 1968, they studied 12 professional programmers and noticed
a factor of 28  difference in time to solve the problem, and a factor of
5 difference in LOC and a factor of 5 to execute the algorithm on the machine.
And all good things came together.

From what I've seen, there is about 100x an individual range (maybe more).
And when groups have to deal with communications, the difference is even
greater (it is far preferable to get a few programmers then a large organization).

The differences a more extreme now, not less.  The job of a
programmer is to understand how to use his computer, not necessarily
how to write code.  If I can find code (hopefully whole programs), my
productivity goes up orders of magnitude.  The attitude is:
    "give me an editor, a compiler and a debuger" and I'm writing code.
But not effectively--do you know how to use software tools?

If you give someone a program to write, a very good programmer will come back
in a week with something that works how you want it to.  A bad programmer won't
take 3 years, but he'll come back in a few months with something awfully hard
to use, prone to core dumps...and you grin and bear it.

I don't think everyone should write code from scratch.  Being able to structure
a program is one thing, being able to edit small patches is something else.
Chief Programmer teams take advantage of this fact.

Part of the problem is the people coming out of the education system.  They need to
write code...many people get degrees without substantial programming projects.
I've found many home-computer "hackers" are better (more structured, understand
configuration control) programmers than many professionals.  Professional doesn't
imply quality, it merely means you are paid.

Everyone is hoping for a "magic bullet to slay the software werewolf"...but I don't
think it exists.

BTW -- Barry Boehm's COCOMO model lops off the top and bottom 10% of the performers
and concentrates on the middle.


--
marty
[e-mail]  [e-mail]
Member of the League for Programming Freedom