Software Design, then and now

I was reading 10 bad habits to break if you want to become a great developer from a newsletter and couldn't help thinking I could have written it in the 1970s. I am always surprised how much has not changed. The only subject I couldn't have written about was security (#10), because we didn't have internet connections to worry about. (We had other security issues.)

I had to learn most program design concepts from self-study, as program design methods were not being taught in most schools. I learned important lessons from an article in a magazine by Niklaus Wirth.  A light bulb went on when I read about  "designing software by stepwise refinement", later known as top-down design. (#3) I saw no evidence of design methods in any programs written by our engineers, not even the 'software engineer'.  I called it spaghetti code, as it was written in a linear way - module-free.

I was able to test out this top-down design in a fairly complicated project. Although it wasn't large in modern terms, it involved real-time user control and hardware systems that needed to communicate with each other. Although I could use a real-time operating system, I still had to write a lot of code in assembly language. Hey, don't laugh, - you work with the tools available. The design concepts are the same. And they worked!  (#7) 

Each of the "stepwise refinements" of the large problem were described in plain english.  I completed this before writing a single line of code. Really! When I finally began coding, the work was easy - just follow the design descriptions and test each module as you go. Maybe this design method only works in a small or medium project. (I never worked in a large team.)

From the same design concepts, I started coding subroutines with one entry and one exit, so each could be tested with all possible inputs before being used. (#2) It turned out that I was the only programmer who worked this way. The other people writing software coded in a linear fashion without structure or plan - or documentation. For some reason, programmers didn't see the obvious problem of working as if every program was simple, and could be coded in a short time using habits developed in their first computer class.

At the same time, I started documenting software modules, no matter how small, with my name, date, entry and exit parameters, and a functional description in plain english. (#3) The proof of the pudding was that another programmer had no trouble making changes to this system. (When I was tasked with making changes to someone else's undocumented spaghetti code, it was a real headache!)

By designing before coding, and testing each module early, final software testing went quickly, because most of the bugs had been removed early. In fact, people were amazed that the system went into use with no bugs - unusual at the time. The only complaint I remember was an error message on the screen that said "Try again stupid". Hey I was young.