Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology (2015)

mcfunley.com

Post reply on HN
Print view View original

251–260 of 269 posts

Re: Choose Boring Technology (2015)

#251

Post by willejs »

dnautics wrote: post #226
jmartrican wrote: post #222

Earlier quoted context omitted.

I think this blogpost changed the industry. Maybe it gave us all permission to go with what we know. A million devs sighed in relief. lol

i dont know. ive seen and dealt with so many shit codebases that were justified because python/java/etc are "boring technologies" that had extreme gunning fog index for understanding the code because those boring technologies were not created for the task and were so cornered in to place because of needing backwards compatibility. do you remember pythons miserable asyncio era (or how long it took to remove gil)? hell…

I think you can apply this too strictly. this is really about having informed technical and business conversations and making tradeoffs. It encourages you to innovate, there are tokens, but to be careful. Sometimes its fine to do something in the wrong language if everyone has the experience and tooling/setup and its productive enough, otherwise its time to spend the tokens...

Re: Choose Boring Technology (2015)

#252

Post by jagenabler2 »

insanitybit wrote: post #239
jagenabler2 wrote: post #152

Earlier quoted context omitted.

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

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

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.

Re: Choose Boring Technology (2015)

#253

Post by tpmoney »

altern8 wrote: post #227
thelastgallon wrote: post #225

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…

Yes, that's my preference too and nobody can convince me that an AWS setup is better unless you have millions of users. I think that a lot of devs just think they _have_ to do it that way, or they over-optimize too early and build the ultimate system before they even know if anyone will use the app or site.

The biggest benefit to me as a developer at least in larger organizations that AWS gives is ownership of my stack and needs. I don’t need to file a purchase request for new servers to spin something up or deploy a new application. I don’t need to fight with other departments for the fixed CPU and memory capacities in our virtualization system.

But everything else would be so much simpler and better for most of the things I do if it could just be a normal box with normal software.

In theory I could build that experience with nothing but bare EC2 instances. But once you’re in AWS, they make using their managed things so tempting that convincing everyone else to not use them is an even bigger battle.

Re: Choose Boring Technology (2015)

#254

Post by davnicwil »

k__ wrote: post #242
davnicwil wrote: post #236

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.

[dead]

Re: Choose Boring Technology (2015)

#255

Post by simonw »

insanitybit wrote: post #241
simonw wrote: post #150

Earlier quoted context omitted.

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…

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.

Re: Choose Boring Technology (2015)

#256

Post by cliche »

eudamoniac wrote: post #133
cliche wrote: post #128

I wish there was a jobs board for companies that are somehow vetted for this type of engineering culture. So many jobs are sold as “we’re pragmatist's” and when you show up there’s 5 devs, 50 repos and most of the work is discussing if x requirement should be a new micro service. The product is usually an web app with 10 entities and and an API. Suppose it’s keeping people in jobs

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.

That’s a good shout I miss ruby / rails

Re: Choose Boring Technology (2015)

#257

Post by __MatrixMan__ »

ForHackernews wrote: post #113
__MatrixMan__ wrote: post #73

Earlier quoted context omitted.

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.

Boring isn't bad. Ideas are cheap: often the execution is what counts. Doing a boring thing to near-perfection looks like the Japanese Shinkansen trains that average 1.6 minutes of delay annually and have operated with zero fatal accidents over decades of service.

Sure, if the thing is worth doing in the first place. How many of us can say that about our jobs though?

Re: Choose Boring Technology (2015)

#258

Post by insanitybit »

jagenabler2 wrote: post #252
insanitybit wrote: post #239

Earlier quoted context omitted.

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

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.

Re: Choose Boring Technology (2015)

#259

Post by insanitybit »

simonw wrote: post #255
insanitybit wrote: post #241

Earlier quoted context omitted.

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…

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

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.

Re: Choose Boring Technology (2015)

#260

Post by jaggederest »

Animats wrote: post #158
jaggederest wrote: post #134

Earlier quoted context omitted.

Hey, at least python is now extremely consistent: it's an unpleasant tarpit regardless of whether it's human or AI generated. Ruby, too, rip my native programming language. I remember in the pre-AI era I was doing a quick sample contract employment with a company that had >200 columns in their user table and was manually enumerating them in every query , multiple times. They were using SELECT $1,$2,...$184,$185 from…

That's a different tarpit. That's the problem with object-relation mapping, which is trying to deal with the mismatch between structs in languages and rows in SQL. There are a huge number of such schemes, and they range from somewhat annoying to awful. They're bad across a broad range of programming languages. This is an area where LLMs might actually help. Or make things worse. We'll have to see.

I think the difference I see is with things like Prisma, where there's a type system to lean on and proper nomenclature, or Rails which, despite all the magic, more or less maps columns straightforwardly based on the labels instead of having to $123 and later in the file ensure that $123 is what you think.
Post reply on HN