Keeping Things In The Club By Drowning Everyone In API Complexity

After seven years of doing API Evangelist I have learned a lot about the realities of the technology sector, versus my own beliefs. One of the things that attracted me to web APIs in the first place was the ability to simplify the access to data, content, algorithms, and other resources using a web url. I could get a list of news articles, post a picture, launch a server in the cloud, and many other common business tasks using a simple URL. To me good API design is more about simplicity, than it was ever about REST, or any other dogmatic approach to doing APIs. However, after seven years of doing this, I’m pretty convinced that most folks have very little interest in truly making things simple for anyone.

As API space continues to move forward with efforts to address technical debt, and the cultural issues involved with the technology we are using within large enterprises as a part of the microservices movement–we are simultaneously see other fronts where leading edge practitioners are embracing technical complexity in service of scope, volume, and satisfying the requests of developers down in the weeds, and not taking time to consider the big picture. You see this with trends like Kafka, GraphQL, ad other areas, where we are moving forward with technology that isn’t entirely embracing the web, and introducing some pretty complex approaches to getting the job done.

I get it. The problems being solved are big. There is a lot of data. Complex delivery models. Robust, and highly functional applications. Simple web APIs can’t always deliver at the scope, scale, and satisfaction of the very technical folks involved. I’m not knocking things moving forward, but I am asking if everyone involved is thinking seriously about the big picture, and assessing the costs down the road–as well as those who get left behind. Not everyone will have the resources, knowledge, and ability to keep up, and I actually question if this pace and the complexity going on is actually required–then I get the feeling that maybe it is actually intentional. Survival of the fittest, meritocracy, unicorns, and all the competitiveness that the tech sector loves about itself.

My assessment is that not everyone is intentionally choosing complexity over simplicity. It is just that the current environment doesn’t afford taking a breathe to think about it, and considering whether or not operating at this scope makes sense, and all this data is actually needed, or if down the road this will all truly pencil out. For me, this is when we get to each point in time where we have to stop and ask, how did we accumulate all this technical debt? How did things get so bloated and complex? Oh yeah, we didn’t ever stop and ask ourselves the right questions along the way, and the folks who made the decision have long moved on, and are enjoying greener pastures. Nobody is ever really ensuring there is accountability for any of this, but I guess that is how it all works, right? Moving forward, at all costs. It will be someone else’s problem down the road.

My guess is that folks who are in the business of mastering or developing the latest technology, and always moving on to the next big thing will not see eye to eye with me. However, when you are someone like me who has been doing this 30+ years, and come into many large organizations to help clean up legacy messes, you might agree with me a little more. I’m guessing this is why some high tech companies who are selling the next thing to the enterprise prefer hiring young whipper snappers, who like to move fast and break things. There will always be endless waves of these techpreneurs to hire out of college, as well as companies to sell the latest technological solution to that will magically fix all our legacy technical debt challenges. Circle of life, and all that. Keeping things in the club, by drowning everyone in complexity, and getting rich along the way.