Mike Amundsen is an Author, Speaker, Advisor, and Trainer. This article by Mike discusses 60 years of APIs.
As we look back, Vannevar Bush talked about how people think and make connections. Ted Nelson gave us the hyperlink. Doug Engelbart gave us the mouse, the clicker. Christopher Alexander gave us the notion of patterns in software. Roy Fielding and Ryan Dahl gave us node js and taught us the notion of asynchronous programming ten years ago. Rich Hickey gave us clojure.
Eric Stryker builds toys for children. What Eric had built ten years ago and is still doing today are these little magnetic components that you assemble together to make a robot. You don’t have to know anything about programming. You don’t have to know anything about electronics; you just have to know that they magnetize together and have their own little robot nature, which is what we’re still doing today. We’re talking about no-code and low-code. We’re talking about components. Eric was talking about this ten years ago and was teaching that to children. Remember the past so that we don’t repeat it. There’s so much in the past that we can learn from so we don’t make the same mistakes.
More than 150 years ago, Charles Babbage and Ada Lovelace were the first hardware programmer. Ada Lovelace hated remote work. She had to program Babbage’s machine by sending letters. J.C.R Licklider founded the very first ARPANET, which became the internet later.
One hundred years ago, Paul was thinking about taking audio, visual, and text and creating a network where people could call up on demand, what he called the worldwide network before Tim Berners-Lee. One of the things that we have discovered over the years is our footprint. The influences that we have are vast; they go over 100 years. Figure out ways to expand your reach and syndicate information but not become captive from it.
Joseph Miller put forth the thought, “Those who ignore the mistakes of the future are bound to make them.” We can see things coming at us. We can see bad things on the way and new opportunities. If we’re going too fast, we might even miss the turn. That’s how you make the mistakes of the future. You forget, and you don’t pay attention. And that’s a really important thing for us. Those of us who are building APIs today are affecting the future. We are affecting not just the next ten years but the ten years after that and the ten years after that. What we do today can make the world better or exacerbate the problems that we have. It’s important that we don’t make the mistakes of the future, as well as the mistakes of the past.
In 2016, we were talking about how our APIs affect others on the planet. We were focusing on this notion of automation and robotics in our APIs. The work that many of us do here today can put people out of work and strain governments, tax bases, and earnings. That’s the work that we’re doing. We’re responsible for what happens to the world. Now APIs are everywhere more than they ever were ten years ago. That means that we have the opportunity to make changes in lots of ways.
What we create as inputs become outputs for something else, and those outputs become inputs for someone else. Designing autonomic systems is how we get past the robot problems we have today. In 1972, Donella Meadows said, “Running the same system harder or faster will not change the pattern.” This is still good today. We have to change how we think about what we do with APIs. We can’t just do more of them. More isn’t the answer; better is the answer; different is the answer.
More specifically, while designing APIs, think of the next seven generations. The APIs we create today will affect people 100 years from now. We have that opportunity to create a world all on our own, using the influences, memories, ideas, and futures that all great thinkers thought of in the past.
The challenge
What is it that we have seen over the last ten years that we will see over the next ten years that could sort of surprise us or give us a great opportunity? Things go in circles. We need to think of orchestration as part of a system, not as a specific element. When we think about workflow, we must consider how workflow circles back and affects each other.
We need to rethink orchestration. One of the ways we’re going to rethink how current machines communicate is that we will see a lot more domain-specific languages in the future. We will see languages designed specifically to allow machines and humans to talk about a single topic, like GDPR, HIPAA services, buy-in for banking, or record for insurance, etc.
Our AI bots and chatbots are great at mimicking human paranoid schizophrenics. They’re lousy at mimicking healthy thinking, generous human beings. When you unleash a bot, you’re unleashing a paranoid schizophrenic on the rest of the world. You can get GPT chat and any other chat to lie, cheat, steal, and do things that you don’t like very easily. Chatbots are dangerous; instead, consider applying domain-specific languages to focused microworlds like insurance, health, and banking. Computers are not for deciding; computers are for informing and collecting information you couldn’t collect from sources you may not be able to connect to.
Team topologies
Team topologies came on the scene three years ago. Matthew Skelton and Manuel Pais gave us the ability to talk about how teams interact with each other. One of the key elements of their team topologies is a team API, how you communicate with a team and establish that communication. The team topologies approach advocates for organization design that optimizes the flow of change and feedback from running systems.
Fediverse
This is a new idea about how we might replace Twitter with these things called Federated Services based on a protocol called Activity Pub. Evan Prodromou has been working on Activity Pub for almost 15 years. This is not new. He has created identi.ca and StatusNet and is now working on pump.io
Eugen Rochko is the creator of Mastodon. Rochko is convinced that a better way to design and administer social networks exists. We’re talking about a distributed kind of Twitter and Facebook, not owned by corporations but by people. You can start your own server if you want to. This is a huge opportunity and turning point for us.
The thing that ties all of these together is any one person does not own them. They’re open source; that’s what we must focus on. There are dozens of applications already built as part of this Fediverse that connect things together in various ways. So, whether you are on Twitter, YouTube, Instagram, Facebook, Reddit, or Goodreads, you can take advantage of a Fediverse version of this.
To conclude, part of our job as API developers is to make sure we’re not just putting lights and wires in a box but actually moving things forward. If we focus on profits instead of people, we will make the same mistakes as in the past. If we focus on control rather than collaboration, we will make the mistakes of the future. More than anything else, we have an opportunity to think about generations ahead. We are creating the next decades.
