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

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 04 October 2002 11:56 pm, Rob Landley wrote:
> On Friday 04 October 2002 07:32 pm, Alan Chandler wrote:
=2E..
> > b) Writing detailed design documentation before even coding (we had a=
n a4
> > sheet form with details of each major subroutine - what it was for, w=
hat
> > its input and output parameters were etc)
>
> Bureaucracy.  Flowcharting still sucks.  I tend to change the design tw=
o or
> four times in the course of writing ANYTHING.  I usually don't have a f=
ull
> 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 proces=
s. =20
The text in these forms were transfered into code headers when the coding=
=20
started.


> > 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 thin=
g.

We were working in assembler where function names were limited to 6=20
characters.  I would say that we moved into C the amount of comments drop=
ped=20
of quite a bit.  However, I am still of the opinion that most people put =
far=20
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=20
try and get to understand them and in lots of cases there are pages and p=
ages=20
of complex code and absolutely no explanation to go with it.

=2E..
> I went through some code reviews at IBM.  It was a political ordeal, wh=
ere
> 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.=20

Oh dear, you really had it bad. Our code (and design) reviews were mostly=
 peer=20
to peer, so it wasn't a question of "approval" more a cross check on qual=
ity.

I had a period during the 90's where, amongst other things I was responsi=
ble=20
for quality in our subsidiary (300 programmers approx).  One of my mantra=
s=20
was that quality assurance was not about bureaucracy but about adding rea=
l=20
value.  As a manager I had earlier personally suffered when the major pro=
ject=20
in my division went badly adrift (in design terms - but then as a result,=
 in=20
quality of the finished product - and then as a side effect, in money ter=
ms,=20
as the development struggled to reach and end, and then the support costs=
=20
went through the ceiling) as a result of a company wide dictact that we=20
should use Yourdon as our methodology.  I then spent a few years on a cru=
sade=20
to ensure that our "Software Engineering Policy" was constructed in such =
a=20
way that those working on the problem had the ability to decide the best=20
approach to solving it.  One of the approaches that we took was the=20
introduction of process reviews - where the people doing the work reviewe=
d=20
the quality control proceedures to see how they could improve them. =20

- --=20
Alan Chandler
al...@ch...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9n+oNuFHxcV2FFoIRAje8AJ91GcnNCFI/jgGVa84PYlirI7gqoACdHeoH
rt6qgRAN/N3coNVn3EtyXLg=3D
=3DrORG
-----END PGP SIGNATURE-----