Live data from Hacker News

Choose Boring Technology (2018)

boringtechnology.club

11–20 of 137 posts

Re: Choose Boring Technology (2018)

#11
The points often lost here is that (1) this advice is aimed at startups, and (2) the whole concept of "innovation tokens." Any successful business is going to solve some problem which is probably not so obvious and that takes innovative thinking. If you're spending too much time trying to be innovative with your tech stack then you're NOT innovating on your specific difference as a business, and that hold you back (or could bankrupt you).

All of that said, today's tech landscape is far less edgy than the early days of cloud, NoSQL, and NodeJS. I'm not even sure what tech is out there that would qualify as "spending your innovation tokens" other than AI.

Re: Choose Boring Technology (2018)

#12
I want to choose tech that has the least amount of maintenance. For example I had to build a web app thing for something I'm doing. The many frameworks available are of course trivial to string together but now I'm looking at a huge amount of dependencies all that require a lot of maintenance. I went with avoiding all but the the most critical libraries for authentication but is there a better way? I found even writing in OCaml and generating js into a docker file to be hosted by someone else who maintains node.js was actually less maintenance than me using any existing frameworks

Re: Choose Boring Technology (2018)

#13

edit: Apparently "choose boring technology" is just clickbait, and in fact the guy advocates for all the nuanced technology selection advocated here.... so errr, apparently he in fact is saying "don't chose boring technology" or something, whatever. I completely disagree with almost any blanket philosophy on technology. Don't choose boring technology. Choose technology that suits the context: * choose what you like f…

It turns out that it’s impossible to reasonably title any talk or article without it being considered a blanket statement. This is why you attach the talk or article to the hyperlink so people can continue understanding more of what you are saying.

Re: Choose Boring Technology (2018)

#14

While I see how this makes sense, I don't like this. If most people follow this strategy, we will end up with utter stagnation, or even devolution. "Boring" technology also has many hidden costs - most importantly, opportunity costs of not having several times higher productivity due to the warts and quirks of the boring tools. Sure, with enough practice one can work around them but every backwards issue takes a good…

The talk doesn’t say to always choose boring technology. But you might think it does if you read three words and wrote a comment in response to them.

Re: Choose Boring Technology (2018)

#15

Is boring technology even an option in high-velocity fields like ML/AI? I can pick boring databases and boring servers but when it comes to model architectures, model weights, GPUs, serving frameworks, etc. there's been such massive improvements lately that it doesn't feel like anything has settled enough to be "boring". If I need a language model, or an image classifier, or an ASR model, there are older options whic…

> Does choosing boring ML tech mean sitting out on massive recent advancements?

that's the point that for new tech it is hard to see where is the hype and where are real advancements which can be useful, and author's choice not to take the risk.

Say you bought the hype of GPT, and integrated it to your product to unlock new cases, but it also can add lots of confusion and quality issues, which author prefers to avoid.

Re: Choose Boring Technology (2018)

#16
He writes all this philosophy and then concludes with using PostgreSQL instead of mongoDB or nodeJS (? I'm not sure how that was in the same category). PostgreSQL is the opposite of boring technology; I've been using it for over 10 years and am still discovering new and surprising features with new and surprising failure modes; PostgreSQL today is very different from PostgreSQL 10 years ago, but setting it up for true master-master replication is still a clusterfuck and you still have zillions of moving parts in real world use.

I'm lead inevitably to the conclusion that philosophising about tech choices and principles is pointless. Everyone will nod and agree with the principles and tradeoffs and then pick their personal pet technology anyway.

Re: Choose Boring Technology (2018)

#17
This article gets posted a lot, but I find it a little unsatisfying. I think it’s because it’s pretty vague about what “boring” means exactly, so it’s the kind of statement most can agree with, without it actually being a very strong statement.

It’s not wrong per se, don’t choose some technology posted for the first time yesterday. But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea.

The specific languages it calls out are Python and PHP, which IMO are bug-prone languages with serious performance/efficiency implications. Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet).

I would say more important is “write boring code”, and it is easier to write boring to-the-point code in modern languages without implicit null references, with sum types for modeling mutually-exclusive data, and with as many other common pitfalls statically eliminated as is possible.

Re: Choose Boring Technology (2018)

#18
post #16

He writes all this philosophy and then concludes with using PostgreSQL instead of mongoDB or nodeJS (? I'm not sure how that was in the same category). PostgreSQL is the opposite of boring technology; I've been using it for over 10 years and am still discovering new and surprising features with new and surprising failure modes; PostgreSQL today is very different from PostgreSQL 10 years ago, but setting it up for tru…

You're kind of missing the point, unless you're saying that regular PostgreSQL also has interesting failure modes. PostgreSQL clustering may not be boring technology, but that just means you scale up instead of out. If you run out of headroom for scaling up, that probably means you're successful enough that you can take a look at non-boring technology.

Re: Choose Boring Technology (2018)

#19
I feel like this has been misunderstood for years. I note this paragraph:

But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down.

I understand F# more than I understand PHP. By the articles definition, F# is 'boring', and choosing to do something in PHP would be using up an innovation token.

Re: Choose Boring Technology (2018)

#20

I feel like this has been misunderstood for years. I note this paragraph: But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down. I understand F# more than I understand PHP. By the articles definition, F# is 'boring', and choosing…

If it works you and/or your org, then yeah.
Post reply on HN