“Do the best you can until you know better. Then when you know better, do better.”
— Maya Angelou

‍

In the beginning, there was the void, and the void was without form, and emptiness filled the digital expanse. And a voice spoke: "Let there be code," and thus arose the ancient tongues: Assembly, Fortran, and COBOL. The languages were inscribed upon the scrolls of punch cards and magnetic tapes; fed into great, computational beasts whereupon instructions upon instructions poured forth to populate the expanse.

‍

And behold! We still tend to classify systems across the decades along language lines: C, Pascal, Prolog, Smalltalk, Java, C++, Python, Ruby on Rails, etc. No wonder that when it comes to modernizing legacy systems, the typical approach is to look first at converting source code written in one programming language into an equivalent source code in another programming language—a.k.a. transpilation.

‍

Transpilation seems logical and—be still my beating AI heart—eminently automatable. But consider the Chinese Room thought experiment. Proposed by philosopher John Searle, it argues that there’s a meaningful difference between the appearance of understanding and actual understanding.

‍

‍

Rather, modernizing legacy systems should begin with comprehension: in this vast monolith of millions of lines of code, what does what? Where are the seams we can identify to discern relatively discrete components? What is this component’s behavior? What other system elements does it interact with? The more critical the system, the more important comprehension is.

‍

To be sure, transpilation has an important role to play—preferably after the system is analyzed and understood. Otherwise, it’s a bit like assembling a Lego Technic kit without instructions.

‍

Once you have a better sense of what’s happening, it’s much easier to decide on which tools and techniques to use to rebuild the behavior of the system incrementally in modern, easy-to-understand code.

‍

Or, to hand it back to my Book of Genesis-themed LLM co-pilot:

‍

‍And so it was rewritten, and so it was done. From the chaos, the light of well-understood, malleable, modern software shone forth, illuminating a path forward free from technical debt and abundant with opportunity.

‍

News and Views

Irony: the software designed to protect companies instead created the greatest disruption since Petya. It hurt airlines the most, and insurance companies estimate an impact north of $5 billion for the Fortune 500. Reports indicate incremental roll-outs could have better managed risk. And—a harsh realization for this GenXer—by now, Windows is legacy.

‍

Yet another example of how much we rely on software, car dealerships had to resort to pen and paper after CDK Software experienced a cyberattack. A sharp dip in car purchases, a probable $25 million ransomware payment: these are real impacts on the economy and companies.

‍

Speaking of ransomware payments, do you have what it takes to bargain with hackers? The Economist takes us behind the scenes of a negotiation—prior experience with hostage situations a must.

‍

Appearance of understanding vs actual understanding illustration in action: learn how to unmask a bot with four simple words.

‍

From the Orchard

Introducing On a Limb, our podcast celebrating the quiet, consistent work of managing risks to prevent full-blown crises. In this inaugural episode, I speak with Professor Herb Krasner about the risks that poor-quality software and technical debt present to the global business landscape. Also available on Spotify and Amazon.

‍

Curious to learn more? Say hello@mechanical-orchard.com.

‍

——————

Issue first published on July 30th, 2024.

‍