How the Software World and Programming Practices Have Evolved

Programming, or writing software as it is commonly known today, has been my profession for 51 years, and for fun for 10 years before that. Like most things, it has changed dramatically as I have grown up with it.

Starting out in 1960, we had only one manual of about 50 pages, a principles of operation. We coded in machine language, because there was no Assembler and no compilers, and not even an OS. Whenever we ran a new program, we essentially started everything over again (bootstrap). Because of this, programs were seldom more than 50 lines of code. It was about all we could muster without errors, as coding in machine language was little more than being a clerk.

Of course, we used punched cards for input, and punched cards for output, along with the console Selectric typewriter, although there was no printing on the cards. For that, we had to use an interpreter or print them on a huge machine which rocked the floor.

Over time we were able to use a crude assembler, called Symbolic Programming System (SPS) which changed everything. We were out of the clerk business and actually doing some real programming, as now we could write much larger programs.

The First OSes and Programming Languages 

The first crude OSes appeared, which IBM called “Monitor.” Still, there were no access methods or recovery.

In college I was programming on a Burroughs machine and we had Fortran. I learned Algol and made an Algol compiler with Algol. That’s the kind of thing professors did back then. I was a math major because there was no computer science majors. No one was quite certain what to do with computers and software. Machines were expensive and software was free, and we all swapped programs.

In 1970 I went to work for CalTrans (or the California High Department as it was known then), and started off in a programming class of 10 people taught by Leigh Leidig for a few months. While I was at the university, the world had changed, as IBM had come out with System/360, with a real OS and several languages.

Entering the Software World

After class was complete, I went to work writing COBOL programs with an occasional Assembler program, then wrote an editor called Panvalet/CICS interface which predated ISPF, and used by the programming staff at CalTrans. A few years later Jerry Brown was elected governor and he hired Adrianna Gianturco to essentially dismantle CalTrans, and I had to scramble to avoid being laid off. I transferred to a new state agency called Personnel Information Management System (PIMS) whose main task was to completely re-write the state’s aging personnel system, which was hosted on an IBM 7074. IBM didn’t even want to maintain this machine it was so old, so we obtained a 7074 emulator from A.O. Smith and ran it on our System/370 at Teale Data Center (TDC). This is where I started meeting some of the most amazing software people I’ve ever met to this day, starting with Shelby Beach who ran the show at TDC.

I started collecting manuals and going to SHARE in 1974, and learned there was a whole world of new horizons. The software world as we know it was starting to emerge, and programming practices were changing constantly.

Structured programming (no GO TOs) was the rage, along with Venn and Hipo diagrams, replacing the now old-fashioned flow-charts. But we were in uncharted territory, and no one knew where it was taking us. “The Mythical Man-Month” book was published, and everything managers thought they knew about software projects was thrown out the window. Adding more people to a software project, as IBM painfully learned, only made it later.

New programming languages were constantly appearing, most of them forgotten by now.

IBM was being attacked business-wise, with other manufacturers producing “plug-compatible” peripherals, and even software compatible machines, like Amdahl. IBM was not happy, but it survived and the world went on.

I wrote a semi-product called a 3270 data stream optimizer, since response time on systems was very slow and the bulk of it was in telecommunications transmission time (as it is today).

A couple of years later, I met a woman who changed my life, Carol Fields, who I had taught in a programmer training class in 1974. My manager hired her to work with me. She was a very talented Assembler programmer with a background in music. We went to work for the fledgling BMC Software, much to the consternation of our parents, and developed the culture (OCO) and products which laid the foundation for going public in 1988 (our products were 59% of sales).

Best Software Practices 

But back to the primary subject, best software practices. By now, it was becoming evident what worked and what didn’t work.

Software development worked best when done by small teams. Assembler was the predominate language for system software (although IBM used PL/S, a kind of structured assembler, but it was proprietary), and COBOL was widely used for financial software. Fortran was widely used in engineering.

The software market changed dramatically. BMC and others started charging modest prices for software products, primarily to save on the cost of expensive hardware. But year-by-year, it became apparent that software was the real treasure, and hardware costs would keep falling. This became apparent to all when in 1999, AMEX purchased IMS utilities from BMC Software for $100M.

Compensation had changed as well. Stock options were used by software startups (like BMC and others) as incentives for cash-poor but future rich companies, and competition for software developers became intense. The old corporate style of managers making more than their subordinates went belly up, even at the State of California. Newly-created positions had software developers making more than their managers.

High-Level Assembler (HLASM) and Debuggers 

But back to the primary subject yet again. In the systems software business, which I know best, the primary language was High-Level Assembler (HLASM). Evolving from an earlier product IBM called Assembler H, it was developed into HLASM by the brilliant late Dr. John Ehrman who made it into the great tool it is today. It had a rich macro language (still lacking in other languages, such as C and C++, which only have a very crude macro language) and many new hardware instructions which Ehrman contributed to.

The story would not be complete without a very important tool, debuggers. Debuggers had been around for a long time, like TSO TEST and others, but it wasn’t until Dave Cole developed XDC that they became really useful. Cole had a passion for XDC, and it showed in the rich and powerful commands it provided. The software business today would not be where it is were it not for Cole.

I have intentionally left out the history of software development on the dark side, Windows and Linux, because it built on the foundations of the mainframe, with one exception: the culture was completely different. Instead of intently fixing problems, the answer was always to reboot. I worked in this environment for many years, but it was lacking in so many fundamentals, such as recovery and locking, that it was discouraging. I’m sure it has a great history, but I will leave that to someone else who is more of a fan.

And for those that think Google runs the world, it doesn’t. At 40,000 transactions per second world-wide on many systems, it’s non-repeatable searches pale in comparison to IBM’s IMS, which can do 130,000 transactions per second on a single system. 90% of the Fortune 100 run IBM mainframes, as do most banks, credit card companies, life insurance companies, and major manufacturers. There may be a GUI front-end, but underneath that it’s all mainframe.

Best Programming Practices Today

So in the last 50 years, this summarizes what I think are the best programming practices today:

• Writing in a language that is appropriate for what the product is trying to accomplish
• When that language is Assembler, making use of the macro facility
• Writing structured code
• Not re-inventing the wheel. If other software exists, use it if it fits.
• DSECTs for everything. No explicit displacements.
• Symbols for everything; nothing hard-coded
• Small modules, seldom more than a few hundred lines
• Programming documentation (as opposed to customer documentation), should be built-in to the source code, with a pre-amble and logic at the front, and block comments scattered throughout. Years later, you won’t remember why something was done the way you did it.
• Use a first-class debugger, such as XDC
• Use all the capabilities of the platform, such as 64-bit and cell pools
• Build in diagnostics from the beginning: recovery routines, tracing, formatting of control blocks
• Plan for maintenance and expansion; patch areas
• Have a separate Quality Assurance (QA) group. It’s almost impossible to test your own code.
• Use a powerful editor with a fast search facility
• Look at other developer’s code. It can save many hours.
• Implement tools similar to GLib, a powerful facility from the dark side.
• Implement chain pointers outside of control blocks
• Implement control block headers
• Have a good naming convention
• Work with talented people. This cannot be emphasized enough.
• Always write re-entrant code
• Whatever resources you obtain, release them. Even today on the dark side I get messages from products like Google News that the browser says are using too much storage (because they have storage leaks).
• There is no such thing as too much testing. It is a 100x more expensive to have an error at a customer site than correcting it in-house.
• Your reputation is everything in this business
• Check return codes from everything, and issue meaningful messages
• Don’t try to be too clever. A straight-forward approach is best.
• Pre-mature optimization is the root of all evil
• Before you code, think through what you are trying to accomplish. Don’t be too anxious to write code.
• Remember, others will be looking at your code. Make it as clear as possible.
• Try to avoid rigid structures that are difficult to change. Try to make everything extendable.
• Compared to 40 years ago, customers are much more intolerant of errors. They have a business to run, and they expect your code to be that of a professional. Respect them.

---