One reason to use non-boring new technology is if it suddenly enables abilities that were previously not possible.

The trap most engineers fail is that they only think about scaling. It's obviously an interesting problem, but until a company becomes successful it's not really something you should worry about, and for the most part things that (allegedly) scale well are more expensive, slower and harder to maintain.

But there are so many ways to innovate that's not just about scaling: can you make your application faster? What are things you never even considered because you have subconsciously internalised as a physical limit of reality when actually it's not?

One of the examples I'm currently exploring is the idea of moving a large amount of data in memory. I remember decades back when Google announced that it's search indexes are now fully in memory (they proudly announced that any given search query might run through a thousand computers). I cannot imagine how many possibilities it enabled for their product that were not possible before. The experimentation with new technology in pursuit of completely new ways of exploring your problem space should always be encouraged, and if boring technology cannot do it then that's when you give up on it.

I think it's helpful if it brings awareness to the situation.

I've spoken with 70+ different devs working on 70+ different projects of all sizes on my Running in Production podcast[0] and the choose boring tech phrase came up a whole bunch of times, and especially the idea of using innovation tokens. If it helps folks build and ship their app in a quick and stable way, that seems like a big win to me.

[0]: https://runninginproduction.com/podcast/

It must have been a weird coincidence but I listened to a few episodes for your podcast and I've actually heard about boring technology in 100% of episodes I listened to

Hah yeah, coincidence for sure. I don't have hard numbers in front of me but based on reference links to the boring tech site it's been mentioned at least half a dozen times. I know innovation tokens have been spoken about a few times outside of those linked episodes too.

> When someone comes at your approach wielding a slogan, be skeptical.

I do agree. Although the point of the article is to _lean_ more on "boring technology" side of, and paying extra effort when considering adopting newest flashy things.

Having read the article 3-4 time in the last years, I don't think they say "don't use new things", just "not too many new things at the same time"

Perhaps the title should be “err on the side of boring technologies”, although I don’t even agree with that. The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors. Your project may really need to use all beta release software, cause maybe it just does.

It may. But probably it doesn't.

Let's say you've given it the proper consideration, and it's clear beyond the smell of subjectivity that it needs to be flashy stuff, go for it. The point is that this is often not the case, and the argument is to go with boring then.

I would agree that we're talking about the same thing, really:

> The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors

It's _usually_ difficult to take into consideration all the factors of a new flashy thing. The unknown unknowns. Thus _maybe_ choosing a trendy set of technologies might indicate that the exercise of balance and consideration you were commenting and that I do agree with 100%, has not been as honest as possible.

It could be rephrased as: spend your "innovation tokens" wisely.

The author even calls out the slogan as clickbait in the presentation.

For what it’s worth, it’s a great read that I would recommend to anyone in the industry.

They aren’t forcing technologies on you, but driving home the true cost of long term maintenance and investing in the “core stack” that you already have instead of adding N technologies to solve N business problems. This is good stuff.

I generally agree about slogans, but that seems unfair here. "Choose Boring Technology" isn't the sum total of the content, it's essentially the title. If you read past it, there is good stuff.

The author even addresses your criticism, i.e. how the title of the talk makes people focus on the wrong detail level of his thesis...

Should "chose boring titles" be a thing?

Thanks for summarizing the talk so concisely.

Maybe read it before commenting next time.

I wish HN had a feature where it could detect that you clicked the link and disallowed commenting before that. At the very least you’d have to click the link, even if you just immediately click back without reading, and you’d know what you were doing was circumventing the spirit of the place.

Interesting idea! Maybe instead of preventing you from commenting entirely, it just tagged all comments you leave as “have not read article”. I think the shame approach would actually work, but too many people would vehemently reject it for it to ever work.

Perhaps just annotate each comment with how many minutes between clicking the link and making the comment (similar to the green usernames)

That way the reader can decide for themselves. I'm less inclined to object to hasty responses to discussion points than I am to top level comments, but that's just personal choice.

“Choose Boring Technology” is an absolute statement. It’s a mantra. A meme. It demands you follow its lead.

It’s an order from the top. A commandment. A clear requirement. A statement of belief for the masses to follow.

It’s an unequivocal statement, a perfectly confident directive telling you precisely what to do without the slightest equivocation.

It’s not “read this powerful headline but then please read the in depth article only to find we don’t actually mean what is said in the headline, we mean something more nuanced and subtle why did you take our headline seriously?”

So a sufficiently compelling headline goes one step beyond intriguing your curiosity into clicking, it substitutes for the author's entire argument?

Amazing bit of self-justification you have there.

If you want to argue against what the author wrote, by all means. If you intend to argue against a straw man you have concocted out of a three word title, then you will seem a fool.

UH, he covered that specific point in the presentation (humorously).

Yes, specially since different people will have different ideas of what is experimental and what not. Python is boring tech at this point for most people, but not everyone maybe using SAS for data analysis or Java for backend. You will need to evaluate case by case if it makes sense or not to change that stack, there is no silver bullet.

It is a general rule that you can fall back to. Like all general rules there are exceptions, but those exceptions have to be explained. If you do not use boring technology, you will pay a price, so you really need to think if the price is worth it.