All Posts in Industry Commentary

|In: Industry Commentary|Last Updated:

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.

Comments

|In: Cognitive Enterprise|Last Updated:

Yeah, yeah, I know. I should stay out of politics and current events; certainly, if I do, I shouldn’t contribute to our current state of tribalism by affiliating with any political tribe.

But I have to, because (Warning: Breaking Political News follows) in case you missed it, the inmates really are trying to run the asylum. Only they’re failing; also, I’m not being fair to the non-metaphorical asylums, let alone their inmates.

Call me naïve; I can’t help thinking that if we could limit every inmate to statements that are factually correct, then our asylum’s governance couldn’t help but improve.

No, this isn’t a particularly novel sentiment. Worse, merely bemoaning that our public discourse has been polluted by Jewish Space Lasers and preposterous braggadocio about power poles and power lines. doesn’t accomplish very much.

Bemoaning is useless. Fortunately, I think I’ve just designed a way to leverage artificial intelligence technologies to improve the quality of our great nation’s political dialog.

It starts with an ankle bracelet.

But not just any ankle bracelet. This one wouldn’t track its wearer’s location to make sure they don’t violate the terms of their parole.

This one would track the factualness of its wearer’s statements. On uttering something completely or mostly false, the ankle bracelet would emit a deafening sound effect (ah-ooooo-ga!(?)) along with a loud voice yelling “Liar, liar, pants on fire!” or something equally pithy. And unless the wearer immediately retracted the statement it would be ‘posted (what used to be “tweeted”) along with a snarky and disparaging commentary.

The goal would be to humiliate any and every public servant who doesn’t respect basic honest discourse.

Who would have to wear one of these undecorative but useful pieces of information technology?

That would be anyone and everyone who holds or aspires to holding elective or high-level appointive office.

But … I can hear critics complain … wouldn’t this violate the office-holder’s first amendment rights?

I don’t think so, for two reasons.

The first: Nobody (and nothing) stops anyone from saying or publishing anything. The magic AI gadget would be responsive, not preventive.

And second: Very much like a driver’s license, we can define running for office as implied consent.

Now I’m the first to caution that machine-learning-style AI insights aren’t completely reliable. The KJR Honesty-Assessment Ankle Bracelet would only be as reliable as its training data.

A technology and process like this would certainly require an appeals process. We might even imagine that this appeals process would be fair, with published retractions when necessary, and with the cost of investigating the appeal paid by the bracelet manufacturer if the appeal is affirmed, but … fair is fair … paid by the offender if the bracelet’s assessment is upheld.

Bob’s last word: This week’s screed might strike you as satire. Satire was, in fact, my plan.

But as long-time readers know I’ve been warning about the dangers of intellectual relativism and the organizational importance of a culture of honest inquiry for a very long time now, and recent events just reinforce that we as a society need to do something, and the fact-checkers we have in place, no matter how good they are, just don’t scale up enough to cope with the scope of the problem..

I’m not yet convinced we need to do anything quite this radical. But a concerted effort to reinforce the importance of factualness in our public dialog? Absolutely. A process that ridicules, lambasts, embarrasses, and otherwise humiliates the propagandists who increasingly control our public dialog?

Sign me up!.

Comments