CV driven development is just as well guarded against by asking someone to justify their technical decisions based on the requirements and how the solution meets them. So "boring" does nothing to further that.
> More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution
It's linked today, people feel it's relevant today. This isn't a historic piece about how the tech industry used to be, people reference this post today.
> around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn't take off and was a dead end.
Yes, they should have had a discussion about their requirements and which technologies would have solved them.
> Then you consider it boring.
Then "boring" is useless and you should just say "I know this technology well and it maps to our use case well" and be able to justify that.
> CV driven development is just as well guarded against by asking someone to justify their technical decisions based on the requirements and how the solution meets them. So "boring" does nothing to further that.
It doesn't though. It's very easy to manufacture reasons why "shiny new thing" is the objectively right fit for something, even when it's not.
The word "boring" is well-chosen because it's addressing a bias most engineers have towards the interesting and new. It's a reminder: that fun new tech you really want to try here may not be, probably isn't, the cold-hearted best choice, if you're being practical and business-minded.
On a meta level, this thread shows how rejecting boring leads to bickering.
Our natural default as engineers is to choose exciting tech that invites debate. At scale, across many choices, those debates become drama. For some people, that drama is fun. For most people, that drama is the worst kind of boring. Most people would want to limit that drama by setting a sensible, sane default.
As I see it, the objection to boring-as-default reflects a tolerance for drama that uses "technical" arguments to override business priority. It's a signal that we engineers can't manage our own impulses, let alone our complexity budget, so management has to step in to baby us.
The obvious parody argument is that by introducing "boring" as a term there's now confusion preventing discussion based on real technical merits.
> so management has to step in to baby us.
An engineer wrote that post lol
Replacing one bias with another feels silly, I can justify bad decisions just as well either way. Just have real discussions about the technical merits, not that crazy of an idea.
You seem to agree with the lecture/article but disagree with the title.
However, it's influenced a lot of people for more than a decade and the snippy title might well have something to do with that.
I don't agree with the article though and I dislike the influence it has had. I have seen engineers use "Boring" to justify "I know this technology" for situations where that technology is a bad fit.
Conversations about technical solutions are bespoke, there is no one term that can or should be used to guide them.
Poor choices whether influenced by this article or engineers chasing CV points are no different. Boring technology is a tool or communication device like any other. I hope in your situation you were able to influence the engineers utilising it poorly to reconsider.
The point is exactly that - bad decisions happen when your reasoning is based on silly terms like "boring" or "hyped" or whatever. The solution is to discuss the merits of each solution as it pertains to the problem space, which "boring" does not help with (and obfuscates).
While it shouldn't be the absolute guide for every technical decision, it helps to have abstractions to capture the intuition and years of experience that goes into choosing a solution. It can make the discussions smoother.
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.
> 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.
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.
I'm sorry but it doesn't seem like you've actually read, or at least internalized, the article? These are direct quotes:
> 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.
I've read it a dozen times at least since it's been released. I don't think you're understanding my criticism. The payoff of the article is and has been that people say "choose boring technology", which is bad. The substance of the article is that "boring" is a valuable proxy word for things that may actually have value, which is a bad thing.
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.