4 ms·

That's exactly what YAGNI/KISS encourages. Don't make things more complicated than they need to be right now. That includes used technologies. I'd much rather

That's exactly what YAGNI/KISS encourages. Don't make things more complicated than they need to be right now. That includes used technologies. I'd much rather use a simplistic tool while I still get away with it, risking having to switch to a more complicated tool later, than starting off with something way too complicated for what I need. Chances are the difficulty isn't in switching from REST to SOAP, or the other way around, but in dealing with the all the assumptions that permeate those 50 KLOC. In the end it just comes down to having a clean code base that can be steered in another direction. Note that I only mean not dealing with what cannot be easily be foreseen. Turning a blind eye to what you should know will soon be a problem, is a different story. As an example, if you ignore concurrency from the start, that will be hard to set straight later.

amarkov 9y ago
But you can't just decide to avoid making assumptions, because the shape of your API strongly dictates the shape of your handler methods. I've never seen an API migration that didn't involve rewriting nearly the entire API layer. Even worse, you have to maintain both the old and new versions of the API code, because turning off the old API endpoint is going to take at least a year.