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

[Rob L. <la...@tr...>]

On Sunday 06 October 2002 03:45 am, Alan Chandler wrote:

> > > b) Writing detailed design documentation before even coding (we had an
> > > a4 sheet form with details of each major subroutine - what it was for,
> > > what its input and output parameters were etc)
> >
> > Bureaucracy.  Flowcharting still sucks.  I tend to change the design two
> > or four times in the course of writing ANYTHING.  I usually don't have a
> > full understanding of the problem until I've seen why my first pass
> > doesn't work...
>
> Remember we were working in assembler - it was part of the thought process.
> The text in these forms were transfered into code headers when the coding
> started.

I started in basic and worked my way up.  To me, assembler has always been 
performance critical snippets you glue into larger programs.  The only 
standalone assembly-only programs I've ever written (not counting the ones 
for my old assembly class) were actually written in a monitor, not an 
assembler.  So it was closer to machine language than assembler, really, 
since there was no text file to binary conversion step except one instruction 
at a time.  (I.E. instruction layout in memory was done by hand.)

> > > c) Writing lots and lots of comments in the code itself.  I remember
> > > writing a comment at the end of almost every line of assembler AND
> > > writing a stand alone comment about every 5 or 6 lines.
> >
> > There's a school of thought that says too MUCH commenting is a bad thing.
>
> We were working in assembler where function names were limited to 6
> characters.  I would say that we moved into C the amount of comments
> dropped of quite a bit.  However, I am still of the opinion that most
> people put far to little explanation of what a lump of code is trying to do
> in to it.
>
> In the past year I have delved into a few pieces of open source software to
> try and get to understand them and in lots of cases there are pages and
> pages of complex code and absolutely no explanation to go with it.

Yup.  Skill at documenting is in short supply.  On the other hand, you have a 
lot of code written by people like Andre Hedrick (Linux kernel IDE guy), who 
apparently do not have english as a first language and are barely 
understandable in email.

> > I went through some code reviews at IBM.  It was a political ordeal,
> > where hidebound bureaucrats imposed their One True Coding Style on
> > everybody else. Not to match the code that was there, but to refactor the
> > whole project to be the way they wanted it to be before approving single
> > line changes.
>
> Oh dear, you really had it bad. Our code (and design) reviews were mostly
> peer to peer, so it wasn't a question of "approval" more a cross check on
> quality.

"Hi, this is tested and it works, can you spot any bugs?"

"I don't like your variable names."

"This is a bug?"

"Yes."

Something very similar to the above conversation did indeed take place.  The 
objection was, in fact, to local variables.  The code reviews in this case 
were well after the fact.  I DID bounce all sorts of stuff off of Pete and 
Glen as I was architecting and implementing it, but that didn't count.

> I had a period during the 90's where, amongst other things I was
> responsible for quality in our subsidiary (300 programmers approx).  One of

Ah yes, the old dilbertian "quality".  "The most noticeable qualities of this 
project are that it smells bad and tends to explode suddenly."

> wide dictact that we should use Yourdon as our methodology.  I then spent a
> few years on a crusade to ensure that our "Software Engineering Policy" was
> constructed in such a way that those working on the problem had the ability
> to decide the best approach to solving it.

The fact that this was in question says to me the company has gone beyond the 
Bureaucracy Event Horizon...

> One of the approaches that we
> took was the introduction of process reviews - where the people doing the
> work reviewed the quality control proceedures to see how they could improve
> them.

I have yet to see the imposition of a procedure that could force people to 
think.  I have yet to see the imposition of a procedure review procedure that 
didn't become recursively abstract and degenerate into navel gazing.

But YMMV.  Back at IBM I tended to come in on evenings and weekends and get 
actual work done, and then present people as a fait accompli things they'd 
dismissed as impossible to do.  Annoyed the heck out of some of them, took up 
a lot of my free time, and half the work got thrown out anyway, but it really 
was the only way to get anything done.

Rob