I see innovation as a guardrail against CV driven development. More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution - I remember more than a handful of projects failing (either undelivered or rewritten well under their expected lifecycle) 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.
> What if you know NodeJS really well?
Then you consider it boring. I'm sure Node and MongoDB were singled out by the author because at the time of writing they were still relatively new and undergoing periods of rapid development and change.
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.
Not a fan of the phrase "CV driven development". It's a great example of a fundamental attribution error.
In my experience, people choose the wrong tech for a handful of reasons, last of which is to further their career.
Using that phrase also implies that the author's intentions are pure but others aren't. As if you have insight into what motivates them.
"architecture by reading blog posts" is as an old boss of mine described it and I liked that better.
That lines up with my experience.
What bothers my about the phrase "CV-driven development" is that it's attributing malintent to others without actually knowing their motivations. I like to believe that what drives most people is their passion for solving problems and building stuff. And when cool, new things pop up that can aid in that, they don't see it as a means to make more money but a means to continue doign what they love: building stuff.
I didn't overuse messaging when I first came across it because I wanted a higher salary, I did it because it was a cool way to solve problems I was running into. Was it the best way to solve those problem? Mostly not. But that doesn't mean I was wasting my company's time because I was greedy.
My recollection is that MongoDB was based on CouchDB, except they dispensed with Erlang & JSON and went with more conventional technology.