I like the general concept, but I think framing it as a small number of discrete tokens isn't quite right. I'd treat the whole thing in terms of debt and risk. Using "non-boring" technology [0] is really just subtracting some amount from your balance. You don't want your balance to go too negative, but carrying some debt is sometimes fine. And some risky bets might turn out to have a huge ROI!

The amounts clearly aren't discrete. Writing your entire app on a new language runtime might be very risky (and also might have large potential ROI!), but choosing a new email provider might not be (random example, but presuming that you can swap out providers fairly easily).

[0] My bigger complaint is really about the vagueness of even deciding what is "boring." How does a new technology transition from being "non-boring" to being "boring"? Apparently that requires a lot of people to ignore this article's advice for a long time, until we collectively decide that those people have had good enough results to consider that technology "boring."

There was another, much older, post similar to this about, I think, "beans" that engineers use to solve problems. If I remember correctly, it was something like, solving a problem costs "beans", and engineers will always use most all of their "beans" to solve a given problem, because it's somewhat "easy" until you run out of them.

Maybe it wasn't beans? But, I've been looking for it for years.

"Weirdness points" are similar: https://www.lesswrong.com/w/weirdness-points

It's a total tangent but AI being so good at developing rust means that my first impression of seeing a rust project has totally changed.

4 or 5 years ago if I had to weigh up two options and one was written in rust it was almost a sure thing that the program was snappy, fast, reliable and that the author was competant.

Now it's a sure fire sign that the project was probably vibe coded. Not saying it can't still be good, I just have a different first impression now

I admit I have a hard time following this logic. If an agent has a baseline intelligence, you can... instead of using boring technology, just DIY/NIH the simplest custom solution which fulfills your requirements. And you'll usually do a better job than a general-purpose software library.

Even if in the other approach, the LLM knows the stack better, you're just going to push the complexity into your client code, so it's not like it's a huge gain to use boring tech stack.

I find agents default to popular which heavily overlaps with boring although you could steer them more boring for sure.

One thing I learned about AI is that, e.g., if you're making websites you're much better off going for php/ruby/elixir, even if you don't like the languages much.

Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo, and so does communication between server and client.

And I say that as a TypeScript and Effect aficionado who has no particular love for neither php or ruby, but they are extremely solid choices to move fast, well, and get excellent performance and tooling out of the box.

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

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.

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

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

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

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

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

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"

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

Feels like some good points but the llm writing makes it feel less trustworthy

I'm reminded of my father in law, who when asked what superpower he'd want, it was flight, so he could get to work without waiting in traffic.

If all of your employees are AI's, clarity of vision trumps choosing boring. And if you're having boring visions... well the world is already full of competition for you, so good luck I guess.

It's bad for building your resume. Managers and employees are rewarded for popular thing. Popularity is mostly a function of novelty. So the (social and therefore economic) incentive structure is inversely correlated with choosing boring technology.

Yeah, it's pretty unpopular among people who like to try out new technology on every given project.

I've found it extremely useful over the years, personally.

This is why it took me so long before giving Go a try, even though on paper it sounds exactly what I want from a language.

I'm glad I finally did, I've been enjoying it.

Only do one new thing at a time.

Don't drive a new car, using new a new type of engine, with a new type of steering wheel, with a new type of entertainment system, .... all at once.

WHEN something goes wrong it will be intense trying to figure it out.

Good question.

Highly likely to not get any other replies as it’s too much uncommon sense.

Pretty sure it was this one linked in the OP. See this footnote: https://mcfunley.com/choose-boring-technology#f4

> A good example of this from my experience is Etsy’s activity feeds. When we built this feature, we were working pretty hard to consolidate most of Etsy onto PHP, MySQL, Memcached, and Gearman (a PHP job server). It was much more complicated to implement the feature on that stack than it might have been with something like Redis (or maybe not). But it is absolutely possible to build activity feeds on that stack.

> An amazing thing happened with that project: our attention turned elsewhere for several years. During that time, activity feeds scaled up 20x while nobody was watching it at all. We made no changes whatsoever specifically targeted at activity feeds, but everything worked out fine as usage exploded because we were using a shared platform. This is the long-term benefit of restraint in technology choices in a nutshell.

It’s not about conservative vs progressive but about “safe, battle-tested, stable” vs “could be amazing future-tech”; and the idea of having a small number of innovative technologies, in particular where they matter, is about allowing yourself to spend all those thought-tokens on areas that matter.

You don’t want to be innovating your logging tech or your database if the old will work because you might spend 90% of your time trying to get your new, creative logging solution working when you should be spending it on the creative part of your business.

I feel like there's a common theme in business advice like this, the bullshit jobs thesis, general alienation of workers, that individuals have a lot of tunnel vision and don't understand the place of a firm in capitalism. The reality is we don't know what strategies will and won't succeed. The system overall works to the extent it works because a hundred thousand monkeys throwing shit at the wall are bound to hit a few targets at least a few times, even if the vast majority of them miss. The larger economy and investment ecosystems are set up under the assumption that most products will never see a single user and most companies will fail. Most employees will spend much of their careers working on projects that get scrapped. It's not much different than life itself. Evolution has no master plan. Most organisms never reproduce. Most species barely make a blip in any ecosystem before going extinct. It sucks for the individuals, but the larger collective goes on and thrives. Life itself does fine. The economy at large does fine, in spite of the ebbs and flows of the business cycle with its bubbles and recessions. Everything still works out in the long run. It's not only okay to fail but it's crucial to the long run success of our collective endeavors.

The vast majority of business strategy is just the lucky survivors assuming in retrospect they were smarter than everyone else. I've been seeing it my entire life, not just in business but in the military, in politics, in sports, in entertainment. Some project leader has one success and coasts off of that forever, failing over and over again afterward because they keep getting rehired, reelected, or re-invested in by inherently conservative investors, hiring committees, team owners, voters, party leaders, who blindly assume winning a Super Bowl means you must have known what you were doing, no matter how many random bounces going your way you had no control over it took.

Over 12 years of popular usage at this point. I still think it's inappropriate for ~90% of the companies using it.

Node.js has been boring for a while.

Do you mean alternatives, like Bun and Deno, or a future direction for itself?

edit: Node is boring, as far as the frontend goes -- a notoriously unstable ecosystem.