Software Isn’t One-Size-Fits-All
When people talk about “integrating software,” they often imagine something tidy: two systems shaking hands, exchanging data, and everyone going home early.
In reality, integration is never a single thing. It’s a spectrum. On one end, you have software that’s almost eager to be integrated. On the other, you have software that resists like it’s trying to hide something.
At the easy end, the software gives you a well-documented API. The IDs it uses are stable. The responses are predictable. If you ask the same question twice, you get the same answer. Working with this kind of software feels like building with Lego bricks; you spend your time designing, not fighting the pieces.
At the hard end, the software has no API. Or if it does, it’s incomplete, undocumented, or unreliable. The identifiers change without warning. Two records that look the same today might have different IDs tomorrow. You find yourself building strange contraptions just to keep track of what’s what. Instead of Lego bricks, you’re working with wet clay; every time you touch it, it changes shape.
The trouble is, most people don’t realize how wide this spectrum is until they’ve been burned by the hard end. They assume all integrations take the same amount of effort. Or worse, they assume all effort is proportional to the number of features. But complexity isn’t linear. A small piece of hostile software can eat more time than an entire cooperative system.
One example: UUIDs. Universally Unique Identifiers are supposed to be stable. That’s the “U” in UUID. But some systems generate them in ways that aren’t truly consistent. Or they change them when records are updated. If you’re trying to keep a connection between two systems, that’s like having the road signs change every time you drive to work. You can still get there, but now you need a map that updates itself on the fly.
If you’re choosing software for your company and you know you’ll have to integrate it, this is the part you should pay attention to. Not just “Does it have an API?” but “Is that API stable, documented, and designed for other systems to use?” Not just “Does it have IDs?” but “Will those IDs still mean the same thing next year?”
The irony is, the easier a system is to integrate, the less you think about it once it’s running. Good integration disappears. Bad integration demands constant attention.
And if you’ve ever had to maintain a bad one, you’ll start making software choices differently. You’ll start looking not just at features, but at the shape of the system beneath them. You’ll pick tools that want to work with you, not against you.
Integration isn’t a single skill. It’s a relationship. And like any relationship, it’s a lot better when the other side meets you halfway.
A mix of what’s on my mind, what I’m learning, and what I’m going through.
Co-created with AI. 🤖
Similar blog posts
More about me
My aim is to live a balanced and meaningful life, where all areas of my life are in harmony. By living this way, I can be the best version of myself and make a positive difference in the world. About me →