Seventeen years ago (a prime number whether or not it was one of my prime insights) I defined “old” as spending more time disapproving of how someone else is living their life than enjoying how you’re living your own.

It complements another common definition: You’re old if you think everything about the past was superior to everything about the present.

This isn’t a definition I can cheerfully embrace, because it would mean acknowledging that the older KJR entries in my archives are better than the words you’re reading right this moment. I’ll leave you to make that comparison.

There is something that is demonstrably superior today to what it was when I was a youth: software.

In the 1960s, the “Software Crisis” was a thing. The software industry was encountering problems with software budgets, efficiency, quality problems, management, and delivery, to name a few of the thornier challenges (if you’re interested, check out “Software Engineering | Software Crisis” for more).

For many, the software crisis reached its apotheosis with NASA’s legendary missing hyphen, whose absence in the software controlling the mission resulted in ground control having to abort its 1962 Mariner I launch – a whopping mistake, costing $80 million in 1962 dollars.

In the 1970s and ‘80s, buffer overflow errors and intrusions were well-known platforms for malware and hacking exploits. Many of us in the industry wondered why operating systems couldn’t be built to stymie them.

Well, truth be told, many operating systems are still vulnerable, but actual buffer overflow exploits are far less common than they used to be.

Supposedly more-secure mainframe systems weren’t immune to design flaws, either. For example, it was common for remote users to inherit CICS access from users who had disconnected from the underlying VTAM communications link but hadn’t logged out from the application. Voila! Instant system access without even having to guess the password.

Many in the KJR community won’t even recall that it once was possible for bad application code to crash anything beyond the module it belonged in.

Sure, we still need to regression test, especially for platform glitches that might crash PROD. So far as application changes are concerned, yes, they can cause data problems – no small thing, but smaller than spreading joy randomly across the PROD environment.

IT has undergone a quiet revolution over the past couple of decades, because where “bug” used to mean “code that causes crashes,” it now means code that misunderstands how the business is supposed to run.

Or, just as accurately, it means code that reflects poorly-thought-out business processes and logic – “business bugs” if you will.

It’s an intriguing dichotomy. Where once upon a time the focus of IT software quality efforts was to isolate the technical damage done by bad code, now it’s to isolate the business impact of code that solves the wrong problems.

This, for IT, is what progress looks like.

Who or what deserves the credit for this progress? Mostly, it’s due to the high technical quality of enterprise application suites. Sure, when it comes to ERP, CRM, and Supply Chain Management systems there’s still plenty to gripe about. Having said that, a CIO from twenty years ago would never have believed the functionality available today for lease.

Also on the who-deserves-credit list are internal application developers and the development standards they bring to the party every day. Because when it comes to vulnerabilities, knowing what creates them and how to avoid doing so has stopped being a retrofit and is now standard practice.

Can you think of anyone or anything else that belongs on the list? Why not visit the Comments and share your thoughts about this.

Bob’s last word: This was a hard column to write, largely because of how much easier it is to be snide and sarcastic. I figured I’d try my hand at something complimentary and see what came of it. What do you think?

Bob’s sales pitch: Want to avoid “business bugs”? Dave Kaiser and I wrote There’s No Such Thing as an IT Project to give you a hand with this.

On CIO.com’s CIO Survival Guide: “Why all IT talent should be irreplaceable.”

What it’s about: The conventional wisdom – that you should fire irreplaceable employees – is backward. Because if your employees aren’t irreplaceable, you’re doing something wrong.