Choose Boring Technology (2015)
mcfunley.com
mcfunley.com
This is one of my favorite blog posts, and it can basically be encapsulated in the idea of "innovation tokens." It is one of the most useful concepts I have had as a PM / eng leader in my career. It helps actually make the the right tradeoffs, and helps even more in explaining those tradeoffs to colleague of all levels. Highly recommend.
Maybe it wasn't beans? But, I've been looking for it for years.
[0] https://widgetsandshit.com/teddziuba/2010/10/taco-bell-progr...
The idea stays: you can jerry-rig a web crawler from pedestrian, readily available parts, and quickly test the idea for which you wanted to crawl the Web.
The point is that bash, xargs, wget, make, etc are well-understood, well-maintained tools. They are not even necessarily simple, but they likely contain very few unknown unknowns.
https://archive.uie.com/brainsparks/2011/07/08/beans-and-nos...
But if beans are scarce, and that's where you can try to find ways to use less beans per function, then the goal is to make the function more efficient by using less beans.
I've tried over the years, but can never find it. All the search engines moving to vector search makes finding something like this near impossible.
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."
“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.”
Boring technology is that where you have an extremely small amount of “I didn’t think that was possible” events occurring. As it states, there’s always some; SQLite’s recent WAL-Reset bug that Tailscale discovered is a perfect example of that.
Actually, on the subject of databases, I think they all break that rule. I’m a DBRE, and can readily state there are an insane number of footguns with all of them. It’s just that, relative to other options, they’re as good as you’re going to get. Also in their defense, nearly every footgun I’ve ever encountered was documented, it’s just that the docs are incredibly dense, and sometimes a bit vague.
> If you choose to write your website in NodeJS, you just spent one of your innovation tokens.
Is NodeJS still considered on the same level of "unknown" / "not-boring" technology as the others listed? By my reckoning it is plenty mature enough to be considered a "boring" choice, and going for bun would be spending and innovation token.
Lots of CSS stuff are still virtually the same, as it only gets additions.
Vue.js API from 10 years ago still works fine in newer versions.
React class components still work. Even Hooks themselves are pushing 7-8 years now.
Also the definitions of "unknown" and "boring" are always up to you. If you have a bunch of experienced `bun` developers in your company you may consider it as the boring tech.
The things you layer on top of Node via npm could count as "not-boring" in this instance, especially with the number of supply-chain attacks each month.
Boring in comparison would be Go where a lot of things are standardized. You still get some non-boring in choosing what libraries to use (if applicable) but generally it's a very dull language/ecosystem.
I'm disappointed that we've fragmented across Node/Deno/Bun, although I was briefly hopeful for Deno since they tried to standardise around ESM and provide a strong standard library. Of course this still had to be bundled for the browser, which has its own issues.
Is NodeJS the simple, solid and rugged way this has been done for a decade now? If not, then it is an innovation.
Second it depends on what your or your teams experience level is.
Have you ever built a serious thing with it and do you have multiple years of experience running and maintaining it? Yes? Then it is probably the boring choice.
Would you be okay with leaving the final product unmaintained for a few years and it would not be a major problem? That may be a factor as well. E.g. a static HTML website needs next to zero maintenance, while a wordpress blog may fall apart every once in a while.
How maintainable would it be if the person who built it leaves? Could someone else pick up the slack right away? Would they need some time to get up to speed? Would it be literally impossible to get up to speed?
How hard is it to get the build system setup if the devs laptop is crushed under a truck? Is it as simple as cloning the project or does it need ritual sacrifice and dark chants and incantations to even get near running?
The boring thing is one that scores all the easy points on these questions.
+1.
I work in a Skunkworks department inside a larger/older company and we recently decided to stop using Python in the future, the company's language.
Node.js, Go, Rust, C#, etc, all of those are extremely boring for us. They're stable and we get things done in minutes. In Python it's like pulling teeth, with constant API changes and refactors from other teams we're struggling to keep up with. Which one is boring? For us, not Python.
The Python developers naturally disagree and say "there must be something wrong with your team if you can't use Python at the same speed and efficacy as us".
If it was for me, JavaScript would stay in the browser.
Probably not in 2026, but it 2015 it was pretty new and shiny.
But innovation tokens is a neat idea, it's not personal - no big bad grumpy old senior being a square about CoolTech2026 - and it's an incentive to have someone that wants to do something cool think about it. The other one in that regard are ADRs, which I think is a very low barrier to entry path into architecture that most developers can do. It too forces the person to consider CoolTech2026 in a wider context - what does it solve, what is used right now to solve it, what other solutions are out there, etc - plus making it a team decision if executed right.
But .... if you run a multi cloud hybrid setup with kubernetes, service mesh, data [lake|pond|ocean] and millions of other fancy words in tech at each and every layer, you resume would look so awesome and you sound wicked smart. And the VP gets 600M budget for AWS and 600 developers, SREs, DevOps, PMO. It is not that things won't run, humans have perverse incentives.
I'm certain a lot of porn/adult industry run their setup like I mentioned with a Romanian dude running the entire infrastructure for $15K - $20K.
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.
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.
Today x86 hardware is super reliable and unneeded complexity in the software stack is the main source of problems.
This seems like the same phenomenon where desktop apps bundle a copy of Chromium.
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.
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 think "New" means untested, but is that true? What if a new project has Jepsen testing, a fuzzing suite, massive compute running tons of oracle tests, etc? I should just say "Choose well tested" instead of "Choose old" - lots of old software is very poorly tested.
Maybe I think that "Old" implies better documentation, but does it? Lots of older projects have insane cruft and weird edge cases that are undocumented and accumulated over years.
Why do we need a metaphor? Why is "innovation token" helpful?
If you're incapable of evaluating a technology in terms of these properties, you aren't a serious developer and "boring" will not save you.
Sit down, write our your requirements, determine candidate solutions, and choose them based on their fit. "Boring" means nothing, it's a vague proxy term. "Well tsted", "performant for our use case", "developers know it", etc mean something.
> MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.
Literally every one of these has caused hilarious and disastrous failures for me in my career. But yep, boring.
> If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens.
What if you know NodeJS really well? Or MongoDb? What if you have empirical, verifiable reasons for why they fit better?
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.
So yes, pick boring tech, defined as the tech you know the sharp edges of.
That is, if someone said two sentences, I would only care about the second one:
1. "We should use this because it is boring"
2. "We should use this because we understand the sharp edges"
I wouldn't care at all about (1) and I'd have a real conversation based on (2).
Any productive conversation that starts with (1) immediately has to follow "can you clarify what that means", so the term is useless at best and thought terminating at worst.
TLDR; #1 and #2 are essentially implying the same thing.
why are you even doing in tech? your users should just use boring technology, pen and paper is great and boring, no need for a computer, much less a saas.
I have no idea why you're talking about Prinicipia Mathematica as if I'm advocating for some sort of formal verification or extraordinary rigor as opposed to my suggestion that people just use their words and have reasons behind their decisions.
> 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.
> More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution
It's linked today, people feel it's relevant today. This isn't a historic piece about how the tech industry used to be, people reference this post today.
> 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.
Yes, they should have had a discussion about their requirements and which technologies would have solved them.
> Then you consider it boring.
Then "boring" is useless and you should just say "I know this technology well and it maps to our use case well" and be able to justify that.
However, it's influenced a lot of people for more than a decade and the snippy title might well have something to do with that.
Conversations about technical solutions are bespoke, there is no one term that can or should be used to guide them.
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.
There are scenarios where all that criteria is met but it's still a bad fit. Boring <> Not boring becomes a trade-off scale. There are understood costs that come with choosing a tech that's not boring and I don't have to explain why.
If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.
I don't think that boring means any of those things. Most people here don't seem to agree with it meaning those things either.
> If an engineer fails to see the nuance then that's a communication issue and I think they'd probably be a hard person to work with regardless if this article existed.
It seems way harder to work with a group of people who all seem to know their in-group definition of a term and resent the idea of just using explicit descriptions that map.
> 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.
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.
It doesn't though. It's very easy to manufacture reasons why "shiny new thing" is the objectively right fit for something, even when it's not.
The word "boring" is well-chosen because it's addressing a bias most engineers have towards the interesting and new. It's a reminder: that fun new tech you really want to try here may not be, probably isn't, the cold-hearted best choice, if you're being practical and business-minded.
Our natural default as engineers is to choose exciting tech that invites debate. At scale, across many choices, those debates become drama. For some people, that drama is fun. For most people, that drama is the worst kind of boring. Most people would want to limit that drama by setting a sensible, sane default.
As I see it, the objection to boring-as-default reflects a tolerance for drama that uses "technical" arguments to override business priority. It's a signal that we engineers can't manage our own impulses, let alone our complexity budget, so management has to step in to baby us.
> so management has to step in to baby us.
An engineer wrote that post lol
In my experience, people choose the wrong tech for a handful of reasons, last of which is to further their career.
Using that phrase also implies that the author's intentions are pure but others aren't. As if you have insight into what motivates them.
What bothers my about the phrase "CV-driven development" is that it's attributing malintent to others without actually knowing their motivations. I like to believe that what drives most people is their passion for solving problems and building stuff. And when cool, new things pop up that can aid in that, they don't see it as a means to make more money but a means to continue doign what they love: building stuff.
I didn't overuse messaging when I first came across it because I wanted a higher salary, I did it because it was a cool way to solve problems I was running into. Was it the best way to solve those problem? Mostly not. But that doesn't mean I was wasting my company's time because I was greedy.
> 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"
> 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"
Rule of thumb. And it's not a rule. It's a bias based on a vague term.
Obviously a straw-man, but also... justify it then? That's the point. You should be able to justify your position. "Cloud scale nosql db" doesn't tell me why you shouldn't choose it.
Then they're not boring. Boring isn't a universal trait, it has to be evaluated within the context of your own team.
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.
There is nothing wrong with evaluating something new and discovering it doesn't work out as expected. That's still a meaningful outcome. Try it, if it doesn't work, replace it. You've learned something in the process, and it's a mistake you won't make again.
At some point you have to trust in the scientific method. The hypothesis->test->evaluate->adjust hypothesis cycle hasn't been beaten for thousands of years.
> 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 to have rational discussions about technical choices, how is this controversial?
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.
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.
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.
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.
That's a great thing to discuss when deciding on the technology. Maybe you should aim for solutions that you know well, or a solution that makes migrating away easy, or maybe you need to do some discovery work, etc.
> You have an objection to something. It's clearly not to the article's point, though.
It's an objection to the nature of the article itself - that technical decisions should work this way, that metaphors like "innovation tokens" are useful, that "boring" is a good proxy word.
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.
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.
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.
I mean, back in the real world of 2015, it does not have any of those things and we know it.
At work we use Rust primarily for services. It was chosen because we're doing a lot of low level and performance sensitive work. The risk we discussed most was devs not knowing the language, which we decided to hedge against in various ways and accepted that risk.
We use Postgres for a lot of data. We've used it a ton at the company and have a lot of expertise. It handles relational data well, Row Level Security helps us with our multitenancy goals, etc. We discussed some risks, like write load on the db, and have mitigations in place for that that I don't want to get into much.
We use gVisor for isolation. This was a more novel pick for us but we had very strict security requirements and the only two options we considered viable were Firecracker and gVisor - we didn't want to require KVM/ hardware support so we went with gVisor and have been very happy with it. There was a sort of "bake off" to evaluate solutions here.
In every case we simply determined our requirements based on product features we needed and decided what to use. Surely we'll regret making a decision eventually but we've had reasons for these decisions every step of the way.
On the other hand, IBM was late getting into integrated circuits. They had Solid Logic Technology, automated machinery for putting transistors into ceramic substrates to make tiny but discrete circuits. That's what powered the IBM System/360. Worked, but kept mainframe prices high and made IBM late to minicomputers.
Innovation when the problem is hard is more interesting. Look at the history of US long range bombers. The B-29 was effective, but underpowered, and had a lot of trouble getting off the ground fully loaded. So, after WWII, the next development was the B-36, which answered the question "what if we scaled up the B-29?"[1] Six propellers, and four jet engines (added late in the design cycle). Was a sky barge, but it worked, as long as no one was trying hard to shoot it down. No flyable aircraft remain. That was the boring technology approach.
After that came the B-47, which answered the question "what if we scaled up a jet fighter to bomber size?"[2] The B-47 was all jets, no props. It needed solid-fuel rocket boosters (!) to help it get off the ground, and a drag chute to slow it down on landing. It was terrible to fly; its operating speed and altitude were too near the "coffin corner" where stall and Mach buffet meet.[3] No flyable aircraft remain.
Then came the B-52. New engines. New airframe. New design. [4] That's the high-risk approach. It worked. Hundreds are still in active service. Outlasted most of its successors, the B-58 Hustler (a supersonic intercontinental bomber), the B-70, the F-111, etc.
On the commercial side, we have Boeing, whose most successful airliner is a variant of the B-737, which first flew in 1967. But that's another story.
[1] https://www.youtube.com/watch?v=vKQYG_fA2uM
[2] https://www.youtube.com/watch?v=l1-urTRxeEM
[3] https://en.wikipedia.org/wiki/Coffin_corner_%28aerodynamics%...
The example I used is incredibly clear-cut, and is the subject of ridicule, but when the boundaries blurrier, people have managed to get away with this sleight of hand.
The point I want to make: the technologist who designs next-gen semiconductor processes or planes that fly faster and further, is categorically, qualitatively different from the one who writes code for ecommerce websites.
No points for guessing which group has lobbied successfully for erasing this distinction.
This is a civilizational issue. Despite allegedly a group of technocrats being charge of society, who do everything in the name of progress, there has been very little progress outside the field of AI during the past decade.
And this was true even a decade ago - this article argues against progress in software engineering - saying all new stuff is useless, and for the record they turned out to be mostly right, all new stuff did turn out to be meh. Curiously, it names node as one of the hot new things of his era - though it's exactly the opposite, node succeeded, because it managed to transplant the validated engineering and mindshare of js devs to the backend and other domains, so even when new, it chose the niche of 'boring' tech.
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 have improved. Drones are really successful. Electric motor control technology has improved considerably. Humanoid robots are in pilot production.
Using the language of the article, I’d say “push all your innovation tokens into agents” is probably a good move. This means the tech your agents work with should all be boring tech.
Another way of saying this is “use in-distribution technology”. If agents are substantially better at Rust than Zig, probably you should use Rust, even if Zig is “better”. The amount that Zig is better is going to get swamped by the amount that in-distribution agents are better.
(This is not a claim that Rust actually is better, just a hypothetical fact pattern for discussion.)
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.
PHP (lets use this as an example) brings already many benefits over a common solution like a TypeScript monorepo mostly operational simplicity. That was already true before AI.
It's boring, very fast and easy to deploy, offers straightforward horizontal scaling, no need to orchestrate containers and/or multiple runtime processes, has excellent html rendering (nothing in JS-land really does), and has very solid framework solutions like Laravel where everything works out of the box.
Those merits existed before AI already.
The issue was that you had to buy into PHP as a language, which was a horrible experience.
But if AI writes most of the code? Suddenly PHP becomes an excellent candidate to choose for many use cases.
If anything, AI makes the choice of programming and languages and software about finding the right tool for the job. Somehow the industry instead keeps vomiting React/Tailwind slop which are the right tool for 1% of the jobs.
I hope to have cleared the concept.
If we get to the point where AI tools are able to consistently able to produce desired results within strict performance and security constraints, without having to make the same tradeoff between delivery velocity and final quality, why would we not have them target the lowest level feasible for implementation, and cut out all of the middleware cruft that makes everything slow and take up ten times the RAM it actually needs to?
To just yeet in a software engineering wisdom (replace debugging with maintaining, extending, reading, etc as you will):
> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
— Brian W. Kernighan and P. J. Plauger in The Elements of Programming Style.On the other hand, Go code from 2012 and Go code from 2026 looks virtually the same. Conventions are respected, go fmt is the one single formatter, "use the stdlib" is a popular mantra and the code is readable by design.
If I were to codegen a project I wouldn't use anything but Go at this point.
The language isn't huge, the documentation has always been very good, and the patterns extremely consistently across the community. I almost wonder whether it's smaller community has been a benefit, as LLMs have been trained on a tighter set of code samples.
I can't speak for Ruby or PHP.
I dislike macros and languages allowing developers to get creative with their own DSLs.
Can you elaborate more on the slowness you've seen with deploying TypeScript codebases? My experience is that it's improved significantly over the past decade or so. tsc is still kinda slow for large projects, but the rewrite to Go should improve things significantly. Pre-install/post-install scripts can also be slow, but I've always disabled those and haven't yet run into issues. The JS-written bundlers can also be slow, but I use the non-JS ones (esbuild, parcel, bun, etc.) and they're fast enough for me to not care. The main build bottleneck I can think of for a modern TypeScript project would be build plugins, since those are still written in JS/TS.
Serving traffic with Ruby and Python is significantly more expensive than serving traffic with Java or Go.
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
Groan. That's sad.
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 tablename with an enormous list of columns referenced only by offset. That's not python's fault, but I've weirdly seen it more often in python codebases.
This is an area where LLMs might actually help. Or make things worse. We'll have to see.
I wouldn't leave technology choices up to LLMs anyway unless you give them all the context and requirements. And this is where experienced software developers come in, who know and / or have experienced the short and long-term effect of technology choices (whether they were boring or not). LLMs can mainly go by what they read on the internet, both hype and sales pitches and (more boring and less frequently posted) retrospectives if you don't give them enough context.
Agree about LLM not choosing tech. Although that could mean dictating upfront or let it choose then review/steer.
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.
1: arraylist. A library will probably do better than you. It’s already written and common.
2: webservers. Sure, you can write one yourself with sockets and a bunch of buffers and string management… or, you could use one of the 100s of existing ones. Which one? Probably a stable and established one.
Once upon a time I wanted a URL /like/this/with%2Fslashes/ where a path parameter could, in rare cases, contain an encoded slash. Legit according to every RFC I checked. Works fine in browsers. But I couldn't get the web server to not convert it to a / before hitting my code. And woe betide thee who wants to make nginx return a custom error code 444.
How many of those are you willing to let your own services and your customers’ data be hit by whole classes of bugs that battle-hardened APIs have already fixed?
You sure you can get an LLM to handle every single one of them on first pass? Would you stake your company reputation and the PII of all your customers on it?
Sometimes it's true. I don't trust myself to write a non-trivial DBMS. I reach for Postgres. And there are some things I just don't want to do - like any kind of cryptography or compression. (I also wouldn't trust myself to avoid cryptography side channels.)
But existing APIs tend to do a lot more than you want, and that brings its own bugs. Consider the sqlite WAL-reset bug that Tailscale found when it corrupted several tailnets' control plane data. They were using a separate database file per network and a custom backup system too clever for its own good. How much control plane data do they have in a network? I'd imagine under a megabyte. They could have written the entire thing in JSON and committed with an atomic rename, and not had the bug. (On the other hand they could've used a single large Postgres.) I don't fault them for the corruption as sqlite is normally extremely reliable, but it just shows how adding things to a system can make it worse.
Or any reverse proxy when you do an HTTP Request Smuggling attack. If you hadn't used a reverse proxy, you wouldn't have been vulnerable because the attack is only relevant to reverse proxies (and forward proxies). Do you need a reverse proxy? Sometimes yes but other times no. You can also prevent that attack by using SCGI, FastCGI or WSGI instead of HTTP as your backend protocol.
I bet there's at least one vulnerability caused by X-Accel-Redirect processing, too.
Remember Log4Shell? The Log4J library had too many features, and some of them could be combined in an unintended way to cause remote code execution. Code worked exactly as intended, it just had too many features. You don't want that.
Remember Heartbleed? The old "battle tested" system turned out not to be.
2. This is a better point but depending on your workload, I don't think this is unheard of. Or at the very least, if your workload is simple, you can grab one off the top of the benchmarks, point AI at it to customise it a bit then you're good. But to be fair this one's a bigger structural investment so I do see your point. For smaller utilities the tradeoff is pretty clear.
If you really, really need some ultra-micro-optimization, you’re obviously not the target of this; but unless you’re doing HFT or the most inner loop of a game engine, the standard library and all its deep integration and battle-testedness is worth the 1% perf hit.
Or better yet, just don't use agents, deliver something better with all the stability and boringness that you have. There's never been a better time than now to produce software that actually seems to work and march along steadily; your competitors are all flailing wildly like morons.
LLMs are better at churning out boring stuff, and you can see a lot of bored people perk up in the age of AI - they can now fire up half a dozen agents so they can express their ideas and see them made reality, instead of leaving their ideas to be ideas because implementing them is boring.
Sure, some people legitimately work on things that middle schoolers can put together, and for those things I suppose using LLMs as a way of just getting them done is a less risky prospect. For those cases I don't really see the point of tossing it over the hedge to LLMs because what exactly are you doing beyond that? These types of projects have almost nothing to actually do beyond the grunt work of wiring together MVC stuff.
It's not as if you're going to now have time for interesting things, as they tend to not exist at all in those types of projects, and they're rarely important or big enough to warrant much thought in terms of distributed systems design and so on.
I guess I can see a situation where someone instead finds time to work on actually interesting side projects because they've basically stopped doing their work manually because it's not something worth doing manually. Personally I don't think I could stand that type of situation because it would feel bad on a moral level as well as on a personal stimulation level.
1. I once worked for a company that had a large Cassandra cluster that was primarily serving the role of a distributed append-only log. This role is as perfect a fit for Cassandra as I can imagine. When we needed a distributed database for authentication, we decided to use Cassandra for it since we had in-house expertise (it was "boring technology") and a cluster we could piggy-back on for a while. When we needed a distributed database for a key-value service, we used the same reasoning and chose Cassandra again. There were many problems with Cassandra that I won't go into, but I will say that straying too far from Cassandra's comfort zone stretched it to a breaking point. And we had some downtime and rough nights because of it. Sometimes boring technology isn't enough, you also need boring workloads for it.
2. I was an early adopter for Rust. Before 1.0, it wasn't clear to most people whether the language would mount to anything. To me, I saw a formal proof assistant being put into programmer's hands and could tell right away it had a bright future. Rust was not a boring technology back then. You might say it is now (for some use cases). Adopting shiny new technologies that measurably improve confidence is not a risk. What's foolish is getting comfortable and complacent with familiar, aka boring, technologies that are difficult to use correctly.
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.
That is tragically sad.
Flight -is it as hard as running? Can I fly faster than I run? Do I get a force field or will I be constantly eating bugs?
I'm sure plenty of people would choose invisibility simply out of extreme introversion.
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
The work is invisible, and impossible to "show off", so it's a bit unrewarding and demoralizing. But hey, someone needs to do it!
It's why senior developers should end up in management or in positions of making decisions, but it's a completely different type of job to software development, where reason and objective truth and whatnot is barely relevant compared to social skills and connections. (this may be inaccurate, I'm not in that 'layer').
New energy crisis this year, the servers held, the company made a lot of money from new contracts via a combination of getting lucky with long-term buy-in contracts and the servers staying up unlike the competition. But there were no heroes, no praise to e.g. the developers putting in the extra hours, etc - it was business as usual, or business as it's supposed to be.
In one case, ten years later, the company is still struggling to maintain their Scala applications in an environment where there's barely any Scala developers (and who charge a premium because it's specialist work), while the main author(s) went on to work at the company behind Scala itself. I'm sure Scala is great for specific use cases (just like every other non-top-10 language out there) but please, think very carefully before trying to build your company on top of it.
I've found it extremely useful over the years, personally.
I'm glad I finally did, I've been enjoying it.
For most places k8s is a complete boat anchor. Ends up being a huge complication and sap on product momentum. Can’t tell you how many outages I’ve seen from k8s misconfiguration and misunderstanding.
In no world would I consider k8s to be boring, I can’t understand how all of these shops have convinced themselves that k8s specifically is the level of abstraction at which they want to be interacting with their infrastructure.
I think k8s happens because a large number of devs look at Heroku-like platforms and bristle at the notion that they could ever be expected to intentionally constrain their brilliant system designs into preexisting, Heroku-style shapes. It’s ego on some level.
That, and a ton engineers are still incredibly bad at trading off hardware cost and compensation/complexity/organizational cost. “Heroku will cost us $2000/month, running k8s on our own hardware will only cost $400/month.” Ok, but your team’s total comp is costing the company on the order of $1MM/year. Is saving $1,600/month on infrastructure to spend $20k/month on dev time a good deal? This happens all the freaking time, it’s crazy how little devs value their own time.
It was fairly obvious it wasn't going to deliver, but usually newer and more inexperienced engineers were extremely enthusiastic and would build the ultimate mess. This was a refreshing blog and presentation that provided a way to communicate to people boring is better, and to ship product.
do you remember pythons miserable asyncio era (or how long it took to remove gil)? hell theres even something to the joke that "docker was created because python's pip is atrocious".
i dont think it changed the industry for better. it created a thought terminating slogan that was used to justify choices that were bad for developer ergonomics and curtail people trying for sonething better
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 more importantly, maintain and operate) and was really all we needed for most useful business software.
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.
We're "scalable" over here. It's a sexy problem to have.
It's a case by case basis. I wonder why people try to encapsulate these things into "philosophies" that are simple minded and stereotypical.
Choose what's better. That's not always necessarily boring technology. Sometimes it is... sometimes it isn't.
The tricky bit I think though, is deciding what actually is boring, since really we should factor complexity in too.
I work a lot with data in python, for in memory data, the most popular choices are:
- pandas - pyspark - polars
Pandas is the most established, although has a lot of technical limitations, as well as complexities.
Pyspark is definitely an "industry standard" choice, but now you're dealing with distributed computing when you probably didn't need too.
Polars is the simplest in terms of API and not being distributed, but then is the newest.
I can easily imagine a discussion where three engineers all agree that they should choose the "most boring" tech, but all choose a different option.
We need to remember that the purpose of using tools is to solve specific problems and achieve goals. Having no tools, too few tools, or too many tools can all hinder the achievement of those goals. We only need to select a few useful, universal, and widely applicable tools. Unless there are necessary and sufficient reasons, we shouldn't easily switch to new tools.
For the tools we choose, one must become truly familiar with and proficient in their use, continuously customize, modify, and improve them, and strive to use them to the fullest extent, thereby significantly improving efficiency and productivity, and solving practical problems and achieving goals faster and better.
At my current job we generally use LINQpad for scripting, and have a lot of tests that use LINQPad scripts.
When I joined, there was a test that relied on an "R" script. Now, "R" might be the best tool for the job, but no one running the test would ever have any "R" experience. In addition, the environment to run "R" has quite the learning curve.
I ported the script to LINQPad. The fact that no one needs to install "R" or figure out how to run "R" is a much more massive timesaver than the fact that "R" was technically better for that one task. (And the script itself is pretty straightforward.)
The example they gave was something like they wanted to use rabbitmq for a new side project (I might be misremembering) but they were forced to make it work with redis instead. The author said that years later he found out that that side project had exploded in popularity and it had coped with it fine because the infra team were already handling the stack and it wasn't some snowflake deployment.
Does anyone remember the post I'm talking about?
> 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.
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.
Highly likely to not get any other replies as it’s too much uncommon sense.
Say it's 2012 and you need a new car. Toyota Corollas have generally proven to be incredibly reliable. The Tesla Model S is brand new: definitely not boring. On paper both meet your needs, so you test drive both. The Tesla is way more fun to drive, and that's appealing, but if you just want your car to work for a long time with predictable maintenance, you should take the Corolla.
Instead I like “only work on impossible problems”
Most of them turn out to be impossible, but some of them turn out to be possible.
I’ve never met anyone who could pick 3 and be confident in getting even one right. Tokens are a terrible analogy for innovation or research.
In hindsight I’ve had to sift through hundreds or more to fine one that worked.
I thought this post was helpful when I first started thinking about startups.
After more time, I think boring tech isn’t worth thinking about.
Shouldn't that be 0 innovation tokens though?
Don't let one affect the other.
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.
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.
Sadly, that is real out-of-the-box thinking.
And generalizations in software development are always wrong.
This should not be new.
Make your shit work. Make it work well. Don't fuck with a thing that's working as desired.
In this way, you'll make everyone's lives at least a little easier.
This should be a mandatory teaching to anyone who wants to use the moniker of "engineer".
edit: Node is boring, as far as the frontend goes -- a notoriously unstable ecosystem.