How to Mess up an API Programme Part 2

Photo by Jan Huber on Unsplash

With tongue still lodged firmly in cheek, the perilous API journey continues.

Don’t Sweat the Details

Photo by Laura Ockel on Unsplash

APIs have been around virtually since the dawn of computing. It’s a little known fact that the original Difference Engine had an undocumented API to calculate pi to a trillion decimal places. You just had to spin the wheels really,  really fast and invent new technology to keep it cool.

Anyone who works in or around software knows what an API is.

You just don’t need to waste time explaining it, much less explain things like REST, GQL, SOAP or anything else. People will surely know what you mean.

You might even imagine you need to get up on a stage, take a microphone, much in the style of a tele-evangelist, raise your hands and proclaim the glory of this technology and the benefits it will visit on the corporation. Or failing that, at least do some Power Point.

But don’t worry. Even if you simply opt for slides, your most beautiful work will still get applause as people are happy to get an hour away from their day job.

Never Explain Why

Photo by Victor Garcia on Unsplash

Facebook have APIs. Amazon have APIs. Netflix have APIs. Google have APIs. They are all successful. Therefore, APIs will make you successful.

People who work in IT know technology is the key. APIs are technology. Therefore APIs are key.

QED.

Modern Developers can Intuit

Photo by ian dooley on Unsplash

Decree your will; “Verily, go forth and make APIs, thou shalt make us a champion in the market.”

Therefore they will self-organise into a team that can work out what you need. And you still don’t need to worry about the detail.

If they’ve never heard of Leonard Richardson, it’ll be fine. What they don’t know can’t hurt. You know, after all is said and done, a developer who is typing really fast is a productive developer.

Iterate Curaga

Photo by Priscilla Du Preez on Unsplash

We know evolution sometimes takes backward or sideways steps. Let it be the way with APIs in your organisation. Forget design. Debates about authorisation protocols and payloads are just so much noise. It’ll quiet down in time.  

If teams argue about the sparsity of their trees, cyclic graphs or the ontology of their data, tell them to just get on with it and stay out the theory. Modern networks are fast, and the cloud is infinitely (so it has been quoted, it must be true...) scalable. It’ll be fine. And if it’s not, breaking changes are not such a big deal anyway (I am going to hell for even joking about this). When you need more money, just tell your boss; it will be more scalable, include some blockchains and have at least 3 learning machines.

Bottom up is Best

Photo by Sharosh Rajasekher on Unsplash

All those legacy back office powerhouse systems with their non-customer centric data structures and fixed width fields were built that way for a reason.

Systems like that stay around a long time. Surely it is because they work.

Drive your API design directly from that heritage and you will bring real colour and richness to future developers. They might even write odes to your foresight to gift them with such pleasures of programming. They will certainly learn by reflecting on how prior generations designed their systems. Marvel they will.

Reassuringly Expensive

Photo by MARCIN CZERNIAWSKI on Unsplash

Everyone (really, everyone) knows that in life, you get what you pay for. Buy the best gateway on the market and charge your users the maximum you can for it. They will know it’s worth it. Free tiers are for the meek who do not really believe in their product and don’t worry about cultivating grass roots adoption.

On the Job Training

Photo by Alec Favale on Unsplash

We already agreed everyone knows what an API is.

Cutting training saves cost.

If people start bothering you with pesky questions about if they should be doing SOAP or REST, or WTF is a maturity model, just tell them to Google it.

If they ask you how many GraphQLs they need, then clearly you need to just offer your most withering look. Don’t even waste your breath. 

If you feel you must do something, then lean on the vendors, they’ll always help you out. These IT behemoths have so much money they are bound to want to help because they exist to grow their business change the world. Just tell them you heard your boss saying we should adopt their cloud platform next. They won’t mind…

Vendors are There for You

Modern IT companies are there for the benefit of their customers. Buy into a whole proprietary eco-system and get all the benefits of that single platform. You know your account rep is paid on the success of customers.

Surely no vendor would be so unenlightened as to pay commission on volume of seats which have no place in a Cloud native environment anyway.

Can you even imagine a return to the dark days of vendors trying to entrap your data as a way to draw you into their warm embrace that is so comfortable, you may never know you even have given away one of your most valuable assets? If your legal team question you, tell them they should worry about something more relevant.

If you want to save some money, you can push that cross platform and migration strategy back a couple of years. Worry later. Make it some other IT leader’s problem.