[rescue] IBM flowchart templates?

[Curious George]

--- On Sat, 1/3/09, Sheldon T. Hall <shel at artell.net> wrote:

> My first programming job was like that, over and over. 
> Design the program, make the flowcharts, show the proposed 
> reports, get it all approved, etc.  Then you wrote the
> program on coding sheets and sent those to the keypunch
> department.  When you got back the punched media (in our
> case, paper tape, later punched cards), you gave it to 
> the computer operators to compile and run during some slack
> time, usually overnight.  If it ran, you got back a
> report.  If it didn't, you got a core dump.  On paper.
> 
> Yeah, it took a while.  Even a one-line change to a program
> could take a couple of days.

Similar experiences here -- but designing embedded systems.
In the days before in-circuit emulators, you wrote your code
(of course, in assembly language), burned a set of EPROMs
(20 minutes each, often 5 or 10 for a complete set), plugged
them into *the* prototype... and hoped it did *something*!

Of course, none of the typical "user I/O" that you would find
on a "real computer".  I.e., no keyboard, display, etc.
The only way to get information out of your *running* code
was with a 'scope *or* liberally stubbing it to do things like:
"if you get to HERE, turn on the motor; if, instead, you take
this branch, turn on the status LED".  (and, Heaven help you if
there was a bug in your stub code!  :-/ )

You quickly learned to:
- start a printout of your *current* code as soon as you start 
  burning PROMs
- examine the *previous* version of the code using the printout
  that just *finished* being printed
- think about how you can stub the *next* version of the code
  if anticipation of any of N different testing results
If you were *good* at it, you could turn the crank twice in a
single 8 hour shift!  (assuming you didn't end up with any
EPROMs that "stopped being burnable")

But, I think the finished product was often much more robust
than the things built nowadays -- you had to *think* about
what your code was doing instead of just blindly throwing 
patches at it, recompiling (on a 3GHz machine) and seeing
what happened.

> On the other hand, I once had to drag out a program that
> hadn't been used in several years, update it, and make it
> part of our normal production process.
> These days, that can be a tough job, since the comments in
> the code are probably the only documentation, and comments 
> tend to get out of synch with the code itself.

Yup.  In our case, adding comments was usually painful
as the assembler would impose lots of restrictions on line
length, program length, etc.  Six character symbol names,
etc.  You learned to be really cryptic and terse with what
you wrote -- and all those damn CAPS!  :<  (remember, the
development tools are running on a 2-3MHz 8 bit processor)

> Back then, though, keeping the flowcharts and program
> narrative updated was virtually a fetish in our shop; you
> did it and got it
> approved before you changed the code itself.  Making the
> mods and getting
> that old program into production was a piece of cake.
> 
> Not that I want the old days back, you understand, but some
> part of it, like
> the level of documentation and the care taken at the design
> stage, could stand a revival.

I've now taken the approach of writing a User's Manual for any
piece of code that I am writing *before* writing the code.  It
ends up acting like a formal specification (since, IMHO, a User
Manual should address every contingency and not just "press GO
to start").  And, it is easy for marketing droids, etc. to
review and grok *before* the product is finished (formal
specifications seem to be too intimidating for these folks...
so, when the product is "done", they are often surprised:
"I didn't think it was going to work like *that*...!"