APIs are tricky things to maintain. Because they’re designed to be open by nature, it’s hard to test every possible way someone could use it. That makes incredibly easy to break if you don’t think through any changes you’re making carefully, with an emphasis on what a developer is expecting. Luckily, there are a few things you can do to limit the amount of times you inadvertently break a bunch of applications with a well-meaning API update.
I transferred teams at work recently, and spent about a week trying to get their code running on my laptop so I can do useful development work. This is in addition to trying to wrap my head around the existing codebase and figuring out how to test my changes. It’s not that the code is bad, it’s just getting all the ****ing components hooked up, communicating with each other, and playing nicely together an exercise in impossibility. Coming from a group that ran everything in AWS, going back to managing all the third-party services in a development environment makes me want to flip my desk over and start screaming about what the **** is wrong with everyone.