Hacker News Reader

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.

This was written over a decade ago. I'd take it in that context. Lots of the tech they're talking about was being cargo culted en-masse.

So yes, pick boring tech, defined as the tech you know the sharp edges of.

I don't think that context is relevant to my comment. I didn't say "in hindsight, those technologies are great!", I pointed out that "boring" is meaningless, and any meaning you attribute to it like "defined as the tech you know the sharp edges of" is better substituted in.

That is, if someone said two sentences, I would only care about the second one:

1. "We should use this because it is boring"

2. "We should use this because we understand the sharp edges"

I wouldn't care at all about (1) and I'd have a real conversation based on (2).

Any productive conversation that starts with (1) immediately has to follow "can you clarify what that means", so the term is useless at best and thought terminating at worst.

Isn't this somewhat semantical? Boring implies a lot of the things you said, especially if it means your team's experience is largely pooled in a particular dev environment. Assuming most boring tech is ubiquitous, it's probably rare that your team, statistically, is deeply literate in some obscure tech - they most likely are experts in some definition of "boring".

TLDR; #1 and #2 are essentially implying the same thing.

insanitybit's point is that "boring" can imply those things, but it can imply other things too. If you have to bring the correct context to make the word make sense, and there's other contexts that could apply that don't make sense, the word isn't helping. You bringing the correct context is doing the heavy lifting.

I guess context clues and the way the post was written had obvious implications - that was my point. I do understand it leaves a little open to interpretation, which is the angle he decided to comment on.

It's not just thought terminating. It's hypocritical

why are you even doing in tech? your users should just use boring technology, pen and paper is great and boring, no need for a computer, much less a saas.

I will say one of my career regrets was kinda being dogmatic about boring tech instead of being pragmatic e.g with new tech

there was a period around 2016-17s when people were building stuff with Node.js | Mongo. but it was risky tech though I had experience in it & turned some of those opportunities down cz I wanted to work with boring ruby/swift(iOS stuff) lol. rookie mistake.

fortunately the market made me wise up - you go where you're wanted.

"boring" means familiar. It should have more known unknowns than unknown unknowns.

So then say that.

The article does say that. Explicitly. It's even got a picture of Donald Rumsfeld to help drive the point home.

Then the word "boring" is pointless and the article is reductive.

Well its understood. Maybe your definition of explicitness is only met by things written like Principia Mathematica.

If it's understood then it's pointless. I also reject that it's understood.

I have no idea why you're talking about Prinicipia Mathematica as if I'm advocating for some sort of formal verification or extraordinary rigor as opposed to my suggestion that people just use their words and have reasons behind their decisions.

> What if you know NodeJS really well? Or MongoDb?

Then they're not boring. Boring isn't a universal trait, it has to be evaluated within the context of your own team.

Then it's useless. If I have to take the context into account then I should be prepared to have a conversation about the requirements and how the technology fits it, which "boring" does not facilitate (and discourages).

Weird take. It's clearly useful as a communication tool. You talk to your team, you say "Let's use boring technology. Read the essay, then we can discuss what boring technology means to us first."

I obviously don't agree that it's useful as a communication tool though. Why not "Use the technology that's appropriate for our use case"? That seems radically better and doesn't suffer from weird misinterpretations or vague terms.

Because people LOVE COMING UP with excuses to try a new technology under the basis that "this is appropriate for our use-case", and if you don't introduce a concept similar to innovation tokens you may find that six months later your project is combining three different unproven new technologies and doesn't actually work yet.

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.

It does happen, but having the ability to pivot quickly is almost always more valuable than dealing with "the devil you know".

There is nothing wrong with evaluating something new and discovering it doesn't work out as expected. That's still a meaningful outcome. Try it, if it doesn't work, replace it. You've learned something in the process, and it's a mistake you won't make again.

At some point you have to trust in the scientific method. The hypothesis->test->evaluate->adjust hypothesis cycle hasn't been beaten for thousands of years.

People also love coming up with any way to use Postgres or whatever thing they're already familiar with and they get to say "it's boring" like that means anything.

> 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?

The boring technology framing is meant to provide a hook to help people "have rational discussions about technical choices". It's a tool for inspiring conversation.

I don't get it. The inspiration is your product requirements, why would I need to say "it's boring" to get things started?

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.

I think this entire disagreement is about language, and in particular the implications of the term "boring".

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 can't believe how many words you've packed into "boring" to justify "boring" being a good word. Let's hope everyone's view of boring is identical - with that many, one word out of place could cause a lot of trouble.

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.

I disagree with you, Simon. I almost always see "Use Boring Technology" to close down conversations, not open them up.

> I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens"

It’s a cute way of saying that you can only do 2-3 new things.

The post is written for an engineer at a startup as a reminder that although it’s green field development, you only have so much runway, so it’s better to focus on what matters instead of trying some new tech because it seems cool.

If you’ve ever had to estimate your stories/tickets/etc in “story points” or “T-shirt sizes” then “innovation tokens” is roughly the same.

If you haven’t had to do that, you’ve lived a charmed life.

> Engineers should understand requirements, risks, tradeoffs, and potential gains.

Ideally. But I’ve worked with plenty of engineers who get far too excited by shiny new tech and overvalue its potential while undervaluing its risk.

Hell, I’ve been that engineer in my misspent youth. The post resonates with many of us because it describes hard-won wisdom of our mistakes.

> New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak.

Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely.

> What if you know NodeJS really well? Or MongoDb? What if you have empirical, verifiable reasons for why they fit better?

In 2015, MongoDB was a dumpster fire (which is still kind of true) and node.js was still kind of new and had enough rough edges that most teams were probably better off choosing some other language/framework.

> I'm a bit tired of "simple" and "boring" and other nonsense words in this field taking up the air in the room that should be spent evaluating solutions on their actual merits.

“Boring” and “simple” are ways to convey that it’s good to be risk averse. It’s a bit of rhetorical flourish that helps drive the point home: choose what you work on carefully because you have limited runway and should spend that runway working on the problems that matter for your business, not new tech that’s orthogonal to it.

> It’s a cute way of saying that you can only do 2-3 new things.

Why? What if doing 1 new thing saves you from having to do 3 old things? Why 2? Why 3?

> The post is written for an engineer at a startup as a reminder that although it’s green field development, you only have so much runway, so it’s better to focus on what matters instead of trying some new tech because it seems cool.

I am not suggesting that you do something "because it seems cool". I'm suggesting that you evaluate the costs and benefits of technology, and that "boring" is not sufficient nor helpful in that evaluation.

> Ideally. But I’ve worked with plenty of engineers who get far too excited by shiny new tech and overvalue its potential while undervaluing its risk.

I've worked with plenty of engineers who dismiss technology because it is "hyped" etc and then try to build systems on top of databases or other tools that were never designe for the use case and fail miserably.

The issue in both cases is engineers not evaluating solutions correctly. "Boring" will not help. I have literally been in a meeting where "boring" and "innovation" tokens were the justification for a technology choice that failed miserably. More than one!

> Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely.

I'm not sure what you mean. There's is presumably some technical solution to the problem you want to solve.

> In 2015, MongoDB was a dumpster fire (which is still kind of true) and node.js was still kind of new and had enough rough edges that most teams were probably better off choosing some other language/framework.

I don't see why you couldn't justify not using Mongo or Node and then determine they aren't fits without saying "they aren't boring enough". In fact, I don't think either of those aren't boring in the sense that document databases/ nosql aren't particularly shocking concepts - the issue was, by far, the implementation.

> “Boring” and “simple” are ways to convey that it’s good to be risk averse.

They are very bad at this.

> It’s a bit of rhetorical flourish

I don't think rhetorical flourish should have much of a place in technical discussions. If you find yourself reaching for rhetorical flourish, you should ask yourself why you can't justify your position on its merits.

> choose what you work on carefully because you have limited runway and should spend that runway working on the problems that matter for your business, not new tech that’s orthogonal to it.

New technology may not be orthogonal to it, it may be critical.

> For example, I may think "New" means untested, but is that true?

The article answers this, and the answer is "no". New technology is one you don't know the details of.

> determine candidate solutions, and choose them based on their fit

That's quite hard to do for solutions that you don't know the details.

You have an objection to something. It's clearly not to the article's point, though.

> That's quite hard to do for solutions that you don't know the details.

That's a great thing to discuss when deciding on the technology. Maybe you should aim for solutions that you know well, or a solution that makes migrating away easy, or maybe you need to do some discovery work, etc.

> You have an objection to something. It's clearly not to the article's point, though.

It's an objection to the nature of the article itself - that technical decisions should work this way, that metaphors like "innovation tokens" are useful, that "boring" is a good proxy word.

You are confusing software with technology. Choose boring technology, not choose old software.

I'm not, the post is what adds fog to what should be clear and direct conversations about technical solutions as per their ability to solve a product concern.

Couldn't have said that last part better myself.

Well your points are making sense in isolation whereas this article is making more sense in general.

> I'm a bit tired of "simple" and "boring" and other nonsense words in this field...

This is hilarious in sense millions more will be tired and exhausted by evaluating new and exciting technology endlessly appearing all the time.

People go by these rule of thumbs which may not be perfect in every single case but they do increase success chances for even sub-par teams as opposed to "rigorously evaluating latest technology"

I don't think it's exhausting to determine if a solution fits your requirements and I don't think much about the people who would find it exhausting. I'm not suggesting some insane formal verification, but you really can't just answer basic questions about how technologies can address problems? Then what is your role? To choose mysql irrespective of requirements?

> People go by these rule of thumbs which may not be perfect in every single case but they do increase success chances for even sub-par teams as opposed to "rigorously evaluating latest technology"

Rule of thumb. And it's not a rule. It's a bias based on a vague term.

Well mysql likely will turnout to be better choice than choosing "Cloud scale nosql DBs" when evaluators have rather limited hands-on knowledge about either of them.

> Well mysql likely will turnout to be better choice than choosing "Cloud scale nosql DBs" when evaluators have rather limited hands-on knowledge about either of them.

Obviously a straw-man, but also... justify it then? That's the point. You should be able to justify your position. "Cloud scale nosql db" doesn't tell me why you shouldn't choose it.

So what's your technology stack? Which criteria did you use when choosing it instead?

I don't have a technology stack. Do you just mean what am I using for current projects?

At work we use Rust primarily for services. It was chosen because we're doing a lot of low level and performance sensitive work. The risk we discussed most was devs not knowing the language, which we decided to hedge against in various ways and accepted that risk.

We use Postgres for a lot of data. We've used it a ton at the company and have a lot of expertise. It handles relational data well, Row Level Security helps us with our multitenancy goals, etc. We discussed some risks, like write load on the db, and have mitigations in place for that that I don't want to get into much.

We use gVisor for isolation. This was a more novel pick for us but we had very strict security requirements and the only two options we considered viable were Firecracker and gVisor - we didn't want to require KVM/ hardware support so we went with gVisor and have been very happy with it. There was a sort of "bake off" to evaluate solutions here.

In every case we simply determined our requirements based on product features we needed and decided what to use. Surely we'll regret making a decision eventually but we've had reasons for these decisions every step of the way.

It's the "don't eat processed food" of software engineering.

> What if a new project has Jepsen testing, a fuzzing suite, massive compute running tons of oracle tests, etc?

I mean, back in the real world of 2015, it does not have any of those things and we know it.

Back in 2015 neither did the "boring" ones cited in the article. The point is that you can at least talk about those things and evaluate them.

At this point, any new programming language or framework adds nothing. Name one paradigm shifting programming language or framework over the last 10 years that has made anything previously not possible possible or even significantly easier.

That has nothing to do with anything.

Phoenix LiveView