> Encouraging your team to be selective in where they place their new bets - and use "boring" aka already-understood technology for the bits that are not going to help solve unique problems - can help avoid expensive mistakes.
Or just encourage your team to have rational discussions about technical choices, how is this controversial?
I feel like I've been pretty clear.
1. "Boring" is a bad term that obfuscates things that do not merit obfuscation. It's like saying "brb" in person instead of "I'll be back in 5 minutes" - "brb" means nothing to me, 30 seconds, 5 minutes, 30? And it saved you like 2 words? Silly, unserious, and fine for casual conversations but not for technical decisions like "what database do we use?".
2. It lets people lean into a bias. I see massive bias away from "hyped" tech. People on HN constantly condemn projects for being "hype" tech with no merit behind their criticism, or at least no expressed merit. It sounds very smart to say "oh that's just hyped" - this is a known bias that extends outside of tech. Calling something "boring" makes you sound smart but it doesn't convey information and it leads to the exact same decisions that "hype" would.
Having a conversation about technology is not hard. It's the job. It's one of the most important parts of the job. It is not worth papering over with some biased wording that is guilty of the same exact failure modes of the approach it attempts to deride.
The term we are looking for here is something that means:
"A piece of technology that has been around for long enough that all of the sharp edges have either been filed off or are well documented and understood. We would not be the first people to solve our particular problem using this stack - in fact we would be using it in a predictable way that many before us have already shown to work. It's widespread enough that many people already know it, both on our existing team and in the pool of people we might want to hire from. We won't get to show off about this - our usage of this technology will not become the thing of legends, or conference talks, or blog posts. Our problems require unique solutions in other areas, but for the bit that accepts incoming web requests and runs some queries against a database we can go with something that's low risk, well established and very unlikely to surprise us."
I think boring is a fantastic shortcut for that, especially if you can trust your collaborators to understand it to mean that.
If you can't trust your collaborators to understand that then sure, you need to find a different word.
A couple of decades ago I helped create Django. One of the achievements I'm most proud of is that Django has graduated over time to being one of the most clear examples of a "boring" technology - it's widely used, stable, reliable, and thoroughly understood.
I could just as easily say "webscale" is great because I can write a paragraph about how it will address all of our scaling problems and carry us into the new decade of infrastructure or whatever the hell.
These paragraphs of "it's good" all sound right in isolation but they're purely negative for actual conversations. Actual technical conversations require understanding what problems have to be solved, under what constraints, and then determining properties within the solution space. I am shocked at how controversial "map requirements to solutions" is, how desperately people seem to want to turn that into a one word conversation as if it's onerous.
I've exclusively seen it used as a thought terminating sentence.