Those Were The Days?! A Humorous Reflection on the Evolution of Software Engineering

Biology insists — and common sense says — that I've started to become that old fogey I used to laugh at in my younger days.

...THIRD YORKSHIREMAN:
Well, of course, we had it tough. We used to 'ave to get up out of shoebox at twelve o'clock at night and lick road clean wit' tongue. We had two bits of cold gravel, worked twenty-four hours a day at mill for sixpence every four years, and when we got home our Dad would slice us in two wit' bread knife.

FOURTH YORKSHIREMAN:
Right. I had to get up in the morning at ten o'clock at night half an hour before I went to bed, drink a cup of sulphuric acid, work twenty-nine hours a day down mill, and pay mill owner for permission to come to work, and when we got home, our Dad and our mother would kill us and dance about on our graves singing Hallelujah.

FIRST YORKSHIREMAN:
And you try and tell the young people of today that ... they won't believe it.

- Monty Python, Four Yorkshiremen

Now that I'm now that old, grizzled software veteran whom I feared in earlier times, I've reflected on how the job has changed — definitely for the better — and how engineers today (me included) are so incredibly lucky to be working with the tools available today.

Image source: "Coding w/ Gedit" by Matrixizationized, licensed under CC BY 2.0

Those older days? Not much to get excited about.

Text Editors

Unbeknownst to modern-day software engineers, prehistoric software engineering did not have IDEs to help: no Visual Studio, IntelliJ, VSCode, Eclipse, Atom, nothing. No autocomplete. No syntax checking. No code navigation. No integrated debugging. Nada.  

Instead, you wrote code in (OMG) text editors like vi or emacs or even Windows Notepad (or edlin, when desperate), enhanced by other tools (who's run lint from the command line recently?). And similar to debating IDEs today, then we debated text editors. Engineers may be able to customize those that were configurable, but in the end, it's a damn text editor. Wrap your head around it.

Tabs vs. Spaces

How many characters to indent has been vigorously debated since the dawn of structured programming - no Fortran's fixed positions, thank you very much - but have you ever debated the pros/cons of indenting with tabs vs. spaces? A senior engineer I worked with was adamant that tabs sped up compilation time due to fewer bytes, and insisted (demanded) that we do the same, IKYN. No supporting data was provided, but s/he who speaks the loudest wins.

Hungarian Notation

Hungarian Notation is (originally) a C/C++ coding convention to assist data type identification through naming, allowing engineers to infer the underlying data types without digging through code, e.g. szName is a null-terminated string, and usCount an unsigned short integer.

Method names became overly convoluted as the data types for the return value and each parameter is baked in; e.g., uiszCountUsersByDomain accepts a null-terminated string and returns an unsigned integer. When the function accepted more than a trivial number of parameters, its name became unreadable and meaningless, so I typically only included the return type.

However cryptic, Hungarian Notation was very useful in pre-IDE days and I used it extensively. With shame, I admit to initially applying it to Java but quickly learned the error of my ways.

Paper-Based Code Reviews

Perhaps difficult to believe, but code reviews predate pull requests and your collaboration tools of choice: physical, in-person, paper-based code reviews. Each engineer printed out the code to review and marked it up: questions, concerns, comments, etc. The code occurred in real-time with all people present in the same room, nothing virtual. The author took hard-written notes — remember, no laptops, notebooks, tablets — and returned to their desk to make the agreed-upon changes. Finito.

Single Display Monitor

Image source: "Big old monitor" by Harry Wood, licensed under CC BY-SA 2.0

Remember these old clunkers front-and-center on your desk?  And let's not mention the incredibly unacceptable screen resolutions. Or how you were restricted to using a single monitor due to hardware limitations, software limitations, hardware cost, physical space, electric consumption, or whatever? Ugh!

In my world, there is no such thing as too much screen real estate: multiple monitors, large screen sizes, higher resolution, virtual desktops - I want more, more, more! At Dell, I had four monitors (19x12, meh) and four virtual desktops for 16 total screens.  My home work environment has two 27" 4K monitors plus my MacBook screen, far superior to what's available on the rare trips to the office.  Even travel is tough because I'm limited to my MacBook's screen (though I do hook up to the hotel's TV when possible). Boy, life is hard!

Primitive Networks

Image source: "modem and phone" by BryanAlexande, licensed under CC BY 2.0

Before the adoption of TCP/IP as the de facto networking standard and the universal availability of the Internet, inter-computer communications were difficult. Businesses sometimes deployed site- or company-specific LANs, but rarely to external companies (only as-needed and at great expense). Dialup modems were all the rage at home until DSL became available in the late 1990s.  Do you understand how exciting 9600 baud could be? No, you don't!

The first distributed application I worked with had the app on the remote system automatically dial a modem to connect to the central system, send the data to be analyzed, download the generated results, and disconnect. Slow and effective, but it worked. . . until someone in Finland flipped a modem toggle and now the remote system can't connect. Weeks of checking phone lines, reviewing log files, and reinstalling applications until checking the modem. Oops.

And Not To Be Forgotten

What else was there? 8.3 file names. Floppy-based software installs with hand-entered license codes. Regularly occurring blue screens of death (much more occasional now). Primitive or non-existent security. Microsoft Radio to keep you entertained while waiting for paid support. No open source software: everything is purchased or written from scratch. I'm sure there's more.

[Fortunately, I never wrote COBOL programs with punchcards, though a friend did during her training at Anderson Consulting.  And make sure you don't drop your stack!]

Oh, you kids have it so easy. . . and with that statement, I've finally become who my grandparents warned me about. Damn.