From: jimf@centerline.com (Jim Frost)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: CenterLine Software, Inc.
Date: Thu, 3 Sep 1992 18:56:04 GMT

lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>In article <jimf.715441613@centerline.com> jimf@centerline.com (Jim Frost) writes:
>>There's over twenty years of hard evidence
>>showing that HLL use results in less buggy code and much better
>>overall programmer productivity in mid-size to large projects to back
>>up my opinion (if you don't think so then compare MULTICS to OS/360
>>and contrast the ESS projects -- they provide excellent examples).

>Programming by committee enforces your requirement to have low expectation
>of performance of any project.  Anything that helps trim the body count
>will have more improving effect than anything else.  HLL may attract too
>many of the wrong kind of people depending.  Management may have hidden
>agendas like hiring 2*N mini-experienced people for 2/3 the total salary
>demanded by N well-experienced people, so you may be stuck.  Such is life
>in a mediocracy :-(.

You are correct, of course, because communication overhead starts
chopping into otherwise productive time.

But you dodge the problem that causes people to hire many people in
the first place.

One person cannot build a large project -- such as a telephone
switching system -- in the time necessary to be competitive.  It's not
possible because the requirements are just too big.  So you have to
hire at least several people to get the job done in less time.  The
more people you get, the slower everything goes, so you try to find a
balance where more people won't get the job done faster.

That balance seems to be at about six or seven people in documented
experience (Brooks even thought so back in 1975).  Unfortunately six
or seven people can't generate a million line program in a year no
matter how hard they try -- they'd need to write about 150,000 lines
of debugged code in that year.  Good programmers -- and I mean *very*
good programmers -- can do *maybe* a third of that if they don't need
to do outside documentation or administration, and don't take
vacations.

I'm sure now you'll tell me that you can do 150,000 lines of code in a
year -- you've probably done two or three thousand in a single day
before, I know I have.  I submit that you can't do it.  In an average
work year of 240 8-hour days you'd be writing 1.3 lines of code a
minute to achieve 150,000 in a year.  That doesn't sound too
difficult, but it assumes that you never have a bug you have to track
down, never have to take a coffee break, never get sick, don't have to
wait for compilers, assemblers, and linkers, never need to test the
code, never get interrupted, don't read news at work (ahem), etc.

In real life you can't do that.  You may sometimes write a couple of
thousand lines of code in a single session, but you'll spend the next
week testing and debugging it.

>>>I always assume that I am writing for someone as good
>>>as I am, or is there a problem with that?
>>
>>Yes, there is a problem with that.  If you're any good at all then
>>statistically speaking it's very likely that the next person to play
>>with your code will *not* be as good as you are.  They'll need to be
>>able to understand and modify your code anyway.  And what if you're
>>the next person and *you're* not as good as the guy who wrote it?
>>Have you ever come across an algorithm implementation you just plain
>>couldn't understand, but which you needed to fix or modify anyway?

>Yes, I needed to study some code to see what it was doing, and doing it
>wrong btw.  I sure wish it had been commented even 1/10th as much as I do.
>I *fanatically* comment.  If they can't figure out what I did, and need to
>modify it, get someone else.  Or is the computer industry another old boy
>network merely there to ensure full employment :-).

Even fully commented code can be *extremely* difficult to fathom once
the algorithms get complicated.  You may not even be looking at the
problem the way that the implementor did (most good algorithms are
derived by looking at the problem in non-obvious ways you know).  Take
a look at some color quantization algorithms sometime, or a
source-difference calculator.  Those are *simple* algorithms, yet you
need to look at the problem just the right way to understand why it
works!  It's harder when the problems get more numerous and complex.

>>Have you ever tried to explain your code to someone who just doesn't
>>get it?  If so, you've already seen the problem.  Now imagine how
>>often that happens in a million line project.

>Why would I want that person in the project at all?

It might be because he might be the best damned channel programmer in
the world, but since everyone else is busy trying to hit a deadline
and his channel programs are perfect, he's assigned to track down an
insidious bug in your code (or elsewhere, because of course there are
no bugs in *your* code).

It can also happen because you can't hire the best programmers all the
time, no matter how much you want to.  There just aren't enough of
them to go around.  Somehow you have to hit your schedule without the
people you'd really like to have.

jim frost
jimf@centerline.com