As a person who this article is saying should be empowered to have more choice, choice is a dog whistle for Not Invented Here. The people you employ to build your software will often make the <i>straight up wrong choice</i> when given the opportunity, and a lot of that time the "choice" will be to homebrew a solution that already exists elsewhere, because it's perceived as simpler than taking the time to understand an existing technology.<p>The reasons that get hand waved away in this article are <i>exactly</i> the reasons you can't ignore consistency across teams. There <i>is</i> value in having just one library that multiple teams use to communicate via HTTP to various services, there <i>is</i> value in members of different teams being able to work across projects due to the similarities in infrastructure. If each team has their own client library for communicating with a service, that's work you've paid for twice, or more.<p>I clicked on this article thinking it would be about choice within the prioritized stack on what to build and when, because <i>that</i> is valuable. Letting the folks building the stuff decide which things to build first is <i>much</i> more valuable than letting them pick between Postgres and MySQL, or memcache vs. redis, etc. (just examples, don't get too wrapped up in them).<p>Sure, we can sit here and come up with exceptions to choice, and yeah I do like being able to choose my IDE, the OS I develop on, etc., but those choices are totally different than which relational database I use, or which web framework I develop with. There, I don't think choice is good, at least not for everyone. Maybe this is written for my boss's boss, I dunno. But as for me, the dev writing the code, I don't really want me (or my colleagues) to have all that much choice.