The Prototype's Language
How "The Innovator's Dilemma" Explains the Demise of Java as the Predominant Payments Language
There’s a reason why we no longer build payments in COBOL.
Payments technology ended up switching to Java or C++ during the 1990s, and it’s now switching to more “modern languages”.
But most engineers wouldn’t be able to tell you why.
And to be fair, it isn’t clear. I recently asked for a book at one of the biggest bookstores in Barcelona, and the attendant used a COBOL interface to search for it. When airline staff search for seats on their screen, they use a COBOL interface too.
After all, they’re all just programming languages, with “if” statements and all that.
Why would they switch languages? Just because COBOL is no longer fashionable?
The reason we no longer use COBOL is the same reason why we don’t use Roman numerals anymore. The use cases have changed, and the tool is no longer adequate.
Welcome to The Payments Engineer Playbook, the newsletter bridging the gap between payments strategy and execution. I’m Alvaro Duran.
Today’s post is the fifth installment on a series I’ve called A Sketch of a Payment Systems Protocol. You can read the first, second, third and fourth installments for free.
Want to be notified when there’s a new post? Hit that subscribe button below.
You want to know a trick to square two digit numbers in your head?
Suppose you want to calculate 49 squared without help. What you do is take the nearest multiple of ten (in this case, 50), and you get the number that stands opposite to that multiple of ten (in this case, 48, because 50 = 49 + 1, and therefore the opposite is 49 - 1 = 48).
The distance between those two numbers to the one you’re squaring must be the same.
You then multiply them. The trick is that the multiple of ten makes the calculation easier (in this case, 48 x 50 = 2400). Then, you add the distance between your number and any of those two numbers, squared (1 squared, in this case, 1).
49 squared is 2401. Double check that.
What’s the trick? Enough to say it is based on math we all learned when we were kids, but have since forgotten. Somebody figured it out because they were using Arabic numbers.
You know, the now classic 1 to 10. With Arabic numbers, having that multiple of ten makes calculations so much easier.
But if you were in Ancient Rome, you would have never been able to figure out 49 squared on your head (IL times IL is of course MMCDI, right?).
The moral of the story is that in formal systems, how you express problems impacts what problems you can solve.
When you decide what infrastructure to use for a project, you're not just making a technical decision. You're also making a social decision, and this may be the more important of the two. For example, if your company wants to write some software, it might seem a prudent choice to write it in Java. But when you choose a language, you're also choosing a community. The programmers you'll be able to hire to work on a Java project won't be as smart as the ones you could get to work on a project written in Python. And the quality of your hackers probably matters more than the language you choose. Though, frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages.
— Great Hackers, by Paul Graham
Most payments technology is currently built by those who once worked at banks. Which means that most of the technology that runs money runs on Java.
But that is changing.
The technological world that Java dominated is nothing like the world we live in now. Four factors, two technical and two social, make all the difference.
First, this is a world where computers are very fast, and very cheap. Never mind Moore’s Law deceleration, many critical workloads fit into one of the instances with 32TiB of memory, 896 vCPUs and 200Gbps of network bandwidth that you can rent from AWS.
Second, scale is not the only thing we care about. We want payments that are available nonstop, even in the face of adversity, and are quick to respond and cheap to run. With excruciating audits, we want payments separated from other processes, run by specialized technical talent. We therefore want payments as part of a microservice architecture.
Third, our ways of living have become dominated by computers. Everything runs on software now, and therefore everything is a computer. Your TV, your car, your doorbell. Your juicer.
And fourth, engineers not only have access, but strongly prefer to build that pervasive software with tools that are open source. Tools they can tinker with, explore and change.
Follow these four factors, and the one thing you must reach is that Java is no longer the right tool for building payments. Like COBOL, another language has taken its place.
And that language is Python.
But “Python is slow!”, “Python is not type-safe!”, “Python is for prototypes!”.
Precisely.
I’m tired of hearing tech visionaries talk about disruption. But no one talks about how Python is a case study of what Clayton Christensen envisioned in his book The Innovator’s Dilemma. A piece of technology once dismissed as an expensive toy by the “professionals”, but one that addressed a crucial need for a certain subset of engineers.
Those who didn’t follow rules, and didn’t have bosses. Those we used to call hackers.
Java is the tool for software designed with UML by a committee. Java is the language run on single machines. Java is software certified by a corporation, sold in a handshake agreement by corporation men.
Python is a tool that helps you run prototypes the fastest. In a technological world where the fast eats the slow, Python dominates.
Python engineers understand that prototypes are never rewritten into products; they are the core of products. They know that a good plan executed now trumps a perfect plan done next week. They trade some of the power they get from modern hardware for software development speed. And they choose to work with a language that is open for everyone to see, to touch, and to modify.
The single most impactful technological choice when building payments is the programming language. It is the most difficult to change. It’s also the choice made the most carelessly.
What is the programming language your payment applications are written in?