When I'm discussing technical solutions with colleagues, especially senior ones, I can point to a tech being "boring" and they'll know exactly what I mean - that choosing it will probably mean better support, smoother rollout, established patterns, etc. I don't have to redefine that criteria every single time.
There are scenarios where all that criteria is met but it's still a bad fit. Boring <> Not boring becomes a trade-off scale. There are understood costs that come with choosing a tech that's not boring and I don't have to explain why.
If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.
I don't think that boring means any of those things. Most people here don't seem to agree with it meaning those things either.
> If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.
It seems way harder to work with a group of people who all seem to know their in-group definition of a term and resent the idea of just using explicit descriptions that map.
> The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.
Well understood software directly coincides with support, rollout, and patterns.
This article is bad. It has led to bad things. It has a bad premise. It has bad ideas.
The correct solution to the problem it wants to address is that engineers should justify technical solutions by mapping product level issues to technical solutions.
That's it.