Re: [comphist] Lost arts from the 8 bit days.

[Alan C. <al...@ch...>]

On Wednesday 02 October 2002 9:26 pm, Eric S. Raymond wrote:

> I am *glad* this kind of programming is dying out.  And I say that as
> somebody who did a lot of it back when it was necessary.  I'll say
> this once:
>
> =09MAINTAINABILITY IS MORE IMPORTANT THAN EFFICIENCY
>
> No, that wasn't the case fifteen years ago, or even ten.  Machines were
> too constrained.  But today, if I were managing a project and caught
> anybody doing tricks like you describe, I'd chew him out but good.  The=
re
> is such a thing as being too clever in the wrong direction, and this is=
 it.

I would say that maintainability has always been more important than=20
efficiency.  It was certainly in my thinking 30 years ago.  In those days=
 I=20
coded in assembler (PDP Macro 11) but we (our project team) spent lots of=
=20
time and effort in=20

a) Making the design simple so that the code would not need to be convolu=
ted. =20
This design was always documented in a technical spec - which would start=
=20
with an overview and progressively get more detailed until...
b) Writing detailed design documentation before even coding (we had an a4=
=20
sheet form with details of each major subroutine - what it was for, what =
its=20
input and output parameters were etc)
c) Writing lots and lots of comments in the code itself.  I remember writ=
ing a=20
comment at the end of almost every line of assembler AND writing a stand=20
alone comment about every 5 or 6 lines.

We did have to do things like pack several flag bits into a word along wi=
th=20
other data, but we always had a detailed documentation showing the layout=
s=20
with comments as to why they were like they were.  There was one particul=
ar=20
system I first developed in 1975, and we were still developing in the mid=
=20
80's.  We had all the internal data structures documented in the "Don't P=
anic=20
Guide".  This was a paper document - of about 50 pages

These projects were often fixed price - delivery of a working system to a=
=20
customer for a fixed amount of money.  Even within the scope of one proje=
ct=20
we felt it was worth the time and effort to do the design and document it=
,=20
conduct design reviews within the projects and do code reviews of peoples=
=20
code after it had been written, but before testing - to check for style a=
nd=20
comments (to weed out the sorts of bad behaviour described in the previou=
s=20
posts).

--=20
Alan Chandler
al...@ch...