API Technology Does Not Have To Mindlessly March Forward
25 Oct 2016
I am seeing more people asking that we put on the brakes when it comes to technology, looking to slow the adoption of new technology, in favor of mastery of the existing, and getting our house in order with the technology we already in play. One of the core tenets of my message as the API Evangelist centers on the importance of doing what we are already doing and doing it better. You can see this message present in my 2014 recommendation on an API strategy for the US federal government--do more of what is already in motion, don't disrupt by just doing the new.
I have seen a lot of API technology float by in the last six years of doing API Evangelist. I can still get excited by some of it, but far less than I did in 2010 when I first started. This is partly because I'm tired, but mostly it is because I've seen a lot of shit float by, and it has to be meaningful in some way to get me excited. I am fairly willing to keep an open mind when it comes to microservices, DevOps, GraphQL, voice, bots, drones, and the other technological frontlines, but I refuse to accept that technology has to mindlessly march forward. This is more about selling us new things than it is every about truly bringing us real solutions to everyday problems.
Whether it's addressing technical debt and monoliths, the security concerns of the Internet of Things, or anything in between, we should always work to step back and ask if the new technology will actually provide a solution, or create three new problems for each solution it brings. I am not anti new tech, I love new shiny tech objects, but I think for our own sanity we should learn to be more thoughtful. New technology trends can be exciting, and fun to play with, but when it comes to production environments, and getting important things done, maybe it should stay in the R&D lab or sandbox until it matures.
Maybe we can spend 2017 just taking care of what we already have in motion, and put a moratorium on any new and exciting projects until we get better at testing, usability, security, and other areas we seem to regularly suffer from in our operations. Maybe we can just do all those API implementations that we have the queue, over the next version of existing resources. IDK, if nothing else, maybe we can just a breather and allow us to play catch up a little, and ponders on what matters most.