NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/programm/2390

Internet Message Format | 1992-08-19 | 5.9 KB

Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!olivea!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!bloom-beacon!eru.mt.luth.se!lunic!sunic!aun.uninett.no!nuug!ifi.uio.no!enag
From: [e-mail] (Erik Naggum)
Newsgroups: comp.programming
Subject: Re: Teaching by Value (was Re: Teaching the Basics)
Message-ID: <[e-mail]>
Date: 19 Aug 92 23:36:02 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Department of Informatics, University of Oslo, Norway
Lines: 88

[e-mail] writes:
|
|  If you look at your programming peers, are you more concerned that
|  they can write easily maintainable code than if they can write
|  super-slick fast routines?  Who do you want on your programming team?
|  Should the majority of programmers be writers of clean, easy to read
|  and maintain code, and only a few are needed to right tight, fast,
|  efficient routines?

Excellent question!  "What are your criteria for selecting a team of
programmers?" should be asked of management, to complete the process.

What I want, and I'm quite adamant about it, is code I can trust.  That
is, meet the spec, survive bad input, report breaches of invariants and
assumptions.  This means that the programmers have to know what kind of
assumptions they make, and how to check to see that they're valid.  If
all programmers on a team consistently do this, you don't need debuggers
when things break -- the error log will have all you need to know what
failed and where.

This should _not_ be removed from production code unless you have space
constraints in embedded systems.  Something unexpected _will_ happen,
and being able to pinpoint the trouble spot and correct it within a few
minutes will be the most important element in customer satisfaction.

My ideal team consist of a "language lawyer", a "code auditor", a "code
surgeon", several tools builders, and a "secretary".  The language
lawyer need not be a full-time team member as long as he's within reach
when there are problems in interfacing to the environment, using
language features, searching for standard utilities, etc.  The code
auditor will keep track of coherence between interface specifications
and code, will see that invariants are not broken, that preconditions
are tested for and post- conditions follow from the code, as well as
test for other assumptions, including what pointers are intended to
point to as well as special values, such as NULL in C.  The code surgeon
is the team head, and everything revolves around his needs to complete
the project.  I'm a firm believer in having as few people implement
central functionality as possible, and if you can't make abstractions
powerful enough to let one person keep track of it, you're already
having a maintenance problem.  The tools builders provide the code
surgeon with tools to get his job done, and take care of incidental
details such as "glue" between libraries and such.  All but the code
surgeon can have apprentice team members, and should have, to explain to
them what is going on, and why.  This looks like the job of good
documentation, but the author of the documentation is seldom a good
critic of his own work until several weeks later.  The purpose of the
secretary is to maintain a project development log, including any
suggestions, decisions, and interface changes were decided upon, what
kind of tools the code surgeon needed and the tools builders had to
build because they couldn't find any suitable existing tool, the hidden
assumptions that were discovered.  The secretary should also work with
the documentation group so that all decisions and assumptions made are
well documented.  There could be a "tools library group" in the
organization which took care of maintaining tools made for several
projects and perhaps generalized them if need be.

The focus of such a team is to get a job done fast and accurately; and
over time, cheaper than alternatives, too.  The massive amounts of
documentation and logs will make it possible to find out what to change
and where if more than cosmetic changes have to be made, and the code
auditor knows and has logged interdependencies.  This is _not_ your
favorite night-time hacker kind of job, and I guesstimate that it
wouldn't make sense if the project was below 500 man-hours, and would
reap the highest benefits for projects spanning several months.

Automated tools could serve many of the functions I have listed above,
but I sincerely think we're far from having any such tools at the
moment.  Besides, the human-human communication aspect should not be
underestimated.

I hope some readers will recognize Frederick J. Brooks' The Mythical
Man-Month in the above, because I've borrowed heavily from him.  I also
know this works very well in practice, given intelligent programmers
with a strong attention to detail.  It does _not_ work with PC
programmers accustomed to working alone and never having to talk to
anybody.  The communications overhead will seem stifling to people who
have not worked in large organizations, and will discourage the
top-notch programmers if they're not the code surgeon.  My experience,
including being a tools builder twice, code auditor once, and code
surgeon four times is that it's tremendously rewarding to be part of
such a team.  Especially the going back to understand what you did, and
it's all there.  I only wish we had had more means of automating the
communications aspects, but mostly, it defies systematization by those
who produce the information -- that's for the recipient (secretary) to
handle.

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      [phone]
                        |  ISO 10744 HyTime   |
<[e-mail]>        |  ISO 10646 UCS      |      Memento, terrigena.
<[e-mail]>       |  ISO  9899 C        |      Memento, vita brevis.