Live data from Hacker News

Choose Boring Technology (2015)

mcfunley.com

241–250 of 269 posts

Re: Choose Boring Technology (2015)

#241
post #150

Earlier quoted context omitted.

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 t…

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.

Re: Choose Boring Technology (2015)

#242

I wonder how much of this universal lesson will be rehashed to fit the aftermath of what's currently going on with vibe coding etc. I think it's pretty likely that in, let's just go for the round number and say 80% of cases, everyone will conclude that just existing well used frameworks / code generator templates where everything's understood and most of the hot paths are well tested is pretty fast to build with (and…

I had the opposite impression.

LLMs can abstract pretty well. They write quality code for obscure frameworks no problem, as longs as you take the time to set up tight feedback loops.

Re: Choose Boring Technology (2015)

#243

2 bare-metals with Linux, Postgres, HAProxy and PHP (or Python/Django) work perfectly fine for 99% of apps that businesses need. This will run with 99.99% uptime, 4-hour warranty from Dell/HPE (failover to the other server). Is also somewhat vertically scalable (upgrade RAM/SSD). Kids who finish high school can be taught to own and run this. But .... if you run a multi cloud hybrid setup with kubernetes, service mesh…

Somebody I was talking to about a web app I wrote in Clojure asked me how I hosted it. He seemed surprised my answer was an $8/month VPS. That might be the wrong solution if it was going to have a million users, but it isn't.

This seems like the same phenomenon where desktop apps bundle a copy of Chromium.

Re: Choose Boring Technology (2015)

#244
post #215

I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and feels sort of unserious. Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. For example, I may thin…

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

Re: Choose Boring Technology (2015)

#245

Earlier quoted context omitted.

I think there's the problem of pretending to be something that one is not - when people have always tried to associate themselves and the things they did with the cool 'in-group' of genuinely inspiring people, to the point where the fakery was in your face - think of companies meaninglessly cramming 'AI' or 'crypto' into their products. The example I used is incredibly clear-cut, and is the subject of ridicule, but w…

> there has been very little progress outside the field of AI during the past decade. Rechargable batteries are much better. mRNA vaccines work. The Rust programming language works. Stacked ICs are working. Even mid-sized cities in Asia now have subways. Self-driving taxis are on the roads. There are multiple fusion power startups, and one or more might succeed. Satellite internet is available and cheap. Heat pumps h…

Most of what you write about falls outside of software engineering or computing, with the exception of Rust - which is something that you could argue is a genuine improvement over SOTA.

Re: Choose Boring Technology (2015)

#246
post #150

Earlier quoted context omitted.

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 t…

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 disagree with you, Simon. I almost always see "Use Boring Technology" to close down conversations, not open them up.

Re: Choose Boring Technology (2015)

#247

2 bare-metals with Linux, Postgres, HAProxy and PHP (or Python/Django) work perfectly fine for 99% of apps that businesses need. This will run with 99.99% uptime, 4-hour warranty from Dell/HPE (failover to the other server). Is also somewhat vertically scalable (upgrade RAM/SSD). Kids who finish high school can be taught to own and run this. But .... if you run a multi cloud hybrid setup with kubernetes, service mesh…

> 2 bare-metals with Linux, Postgres, HAProxy and PHP (or Python/Django) work perfectly fine for 99% of apps that businesses need.

I agree. Simple and effective.

I would add a third small machine to give HAProxy a third vote. The problem with only two machines is that, if communications between them fail, you don't want both believing the other died and doing the wrong thing. You could use that third machine for Postgres backups, which would be smart because Postgress replication is not the same as backup.

Re: Choose Boring Technology (2015)

#248

Earlier quoted context omitted.

There is, it's java/ruby shops. No one wants to use that stuff in current year, so if they're using it anyway, they're pretty likely to be boring tech users.

Last I checked, Java was still more popular than C# (for reasons I can't comprehend).

Most companies are boring and conservative in tech. Just not most "tech companies".

Re: Choose Boring Technology (2015)

#249

I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and feels sort of unserious. Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. For example, I may thin…

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

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

Re: Choose Boring Technology (2015)

#250

2 bare-metals with Linux, Postgres, HAProxy and PHP (or Python/Django) work perfectly fine for 99% of apps that businesses need. This will run with 99.99% uptime, 4-hour warranty from Dell/HPE (failover to the other server). Is also somewhat vertically scalable (upgrade RAM/SSD). Kids who finish high school can be taught to own and run this. But .... if you run a multi cloud hybrid setup with kubernetes, service mesh…

At work I use a tech stack written years and years ago in .Net that runs on a server we own in a colo. We use a CDN for some latency-sensitive serving, but almost everything is self-hosted. It's amazing how cheap it is for us to run a reasonably sizeable application.
Post reply on HN