11 ms·

Choose Boring Technology (2015)

438 points by tosh 2mo ago

euthymiclabs 2mo ago
Software that works year-after-year has never been a commodity. It's boring on the surface. It doesn't get the flashy posts. But I'll choose reliable over new in almost all cases.
- jay_kyburz 2mo ago
  This is why it took me so long before giving Go a try, even though on paper it sounds exactly what I want from a language. I'm glad I finally did, I've been enjoying it.
NickNaraghi 2mo ago
> Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. 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.
- nomel 2mo ago
  There was another, much older, post similar to this about, I think, "beans" that engineers use to solve problems. If I remember correctly, it was something like, solving a problem costs "beans", and engineers will always use most all of their "beans" to solve a given problem, because it's somewhat "easy" until you run out of them. Maybe it wasn't beans? But, I've been looking for it for years.
  - PyWoody 2mo ago
    Not what you're after, but your talk of beans reminded me of Taco Bell Programming. [0] [0] https://widgetsandshit.com/teddziuba/2010/10/taco-bell-programming.html https://widgetsandshit.com/teddziuba/2010/10/taco-bell-progr...
    - krapht 2mo ago
      His example of a web crawler stinks. I can get behind the philosophy, but his specific web crawler example at a minimum needs to retry, respect robots.txt, and rate limit per domain. So no, xargs + curl is a dumb example.
      - nimih 2mo ago
        Based on bot traffic to my personal blog over the past year or so, the minimum viable web crawler apparently does not need any of those things (much to my own personal annoyance, to be very clear).
      - nine_k 2mo ago
        Replace curl with wget, get robots.txt support. Write timed-out URLs into a file for the next identical run. 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.
      - groundzeros2015 2mo ago
        Nah. It’s fine.
    - ChrisMarshallNY 2mo ago
      Speaking of beans, here's a classic (totally different from the main topic. Welcome to Topic Creep): https://archive.uie.com/brainsparks/2011/07/08/beans-and-noses/ https://archive.uie.com/brainsparks/2011/07/08/beans-and-nos...
      - asalahli 2mo ago
        This was a great read, thanks! I've naively tried to stop too many beans-and-noses situations in the past.
  - cwnyth 2mo ago
    This is where efficiency can be applied in two distinct ways. On the one hand, if using more beans means you can solve the problem more quickly, then it is more efficient to the problem solver to do so. 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.
  - contingencies 2mo ago
    You misspelled 'beers'. A boring technology.
  - bch 2mo ago
    I’m vaguely recalling something - and I think the beans might’ve also represented vetos, so one had a limited number of objections to other people’s ideas… quick search revealing nothing so far, though.
    - nomel 2mo ago
      Sounds familiar! I believe it was a simple html page hosted on some university user page. 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.
- thewakalix 2mo ago
  "Weirdness points" are similar: https://www.lesswrong.com/w/weirdness-points https://www.lesswrong.com/w/weirdness-points
- tshaddox 2mo ago
  I like the general concept, but I think framing it as a small number of discrete tokens isn't quite right. I'd treat the whole thing in terms of debt and risk. Using "non-boring" technology [0] is really just subtracting some amount from your balance. You don't want your balance to go too negative, but carrying some debt is sometimes fine. And some risky bets might turn out to have a huge ROI! 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."
  - sgarland 2mo ago
    From TFA: “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.
- eudamoniac 2mo ago
  I think the same way about any personal project. You can either make something unfamiliar, or make it with unfamiliar technology stack, but you shouldn't do both.
- monk_grilla 2mo ago
  I also broadly agree with the post. > 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.
  - williamcotton 2mo ago
    It’s pretty boring at this point.
  - sgarland 2mo ago
    I think calling anything in the JavaScript ecosystem “mature” is a bit of a stretch. This is the same community that brought us left-pad.
    - lkirkwood 2mo ago
      10 years ago though
      - mikestorrent 2mo ago
        And here we are, almost all the complaints from a decade ago still have relevance
      - Cthulhu_ 2mo ago
        Some wounds never heal. Like Angular 1->2.
    - samtheprogram 2mo ago
      That's an insane take. Anything?!?
      - anon48293 2mo ago
        Can you name a single thing in the JavaScript ecosystem which has been stable for 10 years?
- Cthulhu_ 2mo ago
  I think a core problem is that people read online and spend a weekend looking into something cool and get a pretty decent POC up and running. But that's a single person in a weekend, nowadays accellerated by LLMs - what they cannot see (or, something that comes with experience) is how expensive or invasive it would be to apply that in your team or company-wide. 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.
tosh 2mo ago
aged well
mewens 2mo ago
[flagged]
moresVanpersi 2mo ago
[dead]
conrs 2mo ago
Love this post. Surprisingly controversial; it hasn't made me very many engineering friends.
- andai 2mo ago
  It's bad for building your resume. Managers and employees are rewarded for popular thing. Popularity is mostly a function of novelty. So the (social and therefore economic) incentive structure is inversely correlated with choosing boring technology.
  - abirch 2mo ago
    I see it as analogous to people are frequently rewarded for putting out the fire instead of preventing the fire.
    - andai 2mo ago
      I've been noticing this as a solo dev. I need to put lots of work into infra and security, and all I get for it is... the thing not blowing up (hopefully!). The work is invisible, and impossible to "show off", so it's a bit unrewarding and demoralizing. But hey, someone needs to do it!
      - Cthulhu_ 2mo ago
        And the worst part is, because it's invisible, a higher up manager will think "Ah, we don't need these people anymore, let's replace them with juniors, an external company, and/or AI". It's maddening. 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').
    - Cthulhu_ 2mo ago
      Exactly. When I joined the company I'm at now (consumer energy industry), the energy crisis hit and the servers melted from all the people looking to fix their contracts etc. I wasn't directly involved, but loads of developers did a mammoth effort to rewrite old services to prevent this from ever happening again. 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.
theptip 2mo ago
I love this post. It’s also interesting to revisit in the age of agents. 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.)
- epolanski 2mo ago
  One thing I learned about AI is that, e.g., if you're making websites you're much better off going for php/ruby/elixir, even if you don't like the languages much. 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.
  - add-sub-mul-div 2mo ago
    The willingness to reshape society for the benefit of AI rather than shaping AI around humanity paints a very dire picture of the coming decade.
    - epolanski 2mo ago
      I think you're completely misreading what I wrote. 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.
dofm 2mo ago
A problem shared is a problem halved.
tosh 2mo ago
now 11y later i wonder if 'node.js' still needs an innovation token or not
- esafak 2mo ago
  Do you mean alternatives, like Bun and Deno, or a future direction for itself? edit: Node is boring, as far as the frontend goes -- a notoriously unstable ecosystem.
  - xboxnolifes 2mo ago
    They mean as the article describes. Does using node require using an innovation token.
- wmf 2mo ago
  Node.js has been boring for a while.
martythemaniak 2mo ago
The problem with this is that the list of tech that gets boring changes all time, faster than people's opinions. Kubernetes is very boring tech, but if you go through the old discussion threads on this (even from the last year or two), Kubernetes is still cited as some brand new wizbang thing you shouldn't spend tokens on.
- leetrout 2mo ago
  Over 12 years of popular usage at this point. I still think it's inappropriate for ~90% of the companies using it.
  - rzerowan 2mo ago
    Ideally a techthat is not core to the business goals should neither occupy dev/ops time managing it or be so complex that its failure modes are cryptic. It should get out of the devs way and be easy to grok in case of failures.
  - asa400 2mo ago
    Apologies in advance this turned in to a bit of a rant of violent agreement. 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.
insanitybit 2mo ago
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 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.
- bcrosby95 2mo ago
  This was written over a decade ago. I'd take it in that context. Lots of the tech they're talking about was being cargo culted en-masse. So yes, pick boring tech, defined as the tech you know the sharp edges of.
  - insanitybit 2mo ago
    I don't think that context is relevant to my comment. I didn't say "in hindsight, those technologies are great!", I pointed out that "boring" is meaningless, and any meaning you attribute to it like "defined as the tech you know the sharp edges of" is better substituted in. 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.
dwedge 2mo ago
I read a similar blog post years ago about restricting the technologies you use, and making do with a slightly worse option if it means reusing the stack you already have. 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?
- deleted 2mo ago
  [deleted]
- simonw 2mo ago
  Pretty sure it was this one linked in the OP. See this footnote: https://mcfunley.com/choose-boring-technology#f4 https://mcfunley.com/choose-boring-technology#f4 > 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.
  - dwedge 2mo ago
    I can't believe I was asking about the same article. The flow of time made it feel different and I forgot this was one of my all time favourites that I've been trying to re-find for years. Thank you
exabrial 2mo ago
nawh. 50x node modules, typescript out the wazoo, all the state in the client (where you can't see it in prod), the most over-complicated UI, paired with async callback spaghetti is what you do these days. We're "scalable" over here. It's a sexy problem to have.
westoque 2mo ago
i just did an AI hackathon and 90% of the submissions were written in TypeScript and Next.js which is mostly due to the training data. AI is skewed to use these tools by default vs the best for the job.
geophile 2mo ago
Think inside the box! Sadly, that is real out-of-the-box thinking.
Animats 2mo ago
Some of this may have been a reaction to the era of Javascript framework churn. There were way too many different technologies for doing roughly the same job. They all more or less worked. 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 https://www.youtube.com/watch?v=vKQYG_fA2uM [2] https://www.youtube.com/watch?v=l1-urTRxeEM https://www.youtube.com/watch?v=l1-urTRxeEM [3] https://en.wikipedia.org/wiki/Coffin_corner_%28aerodynamics%29 https://en.wikipedia.org/wiki/Coffin_corner_%28aerodynamics%... [4] https://www.youtube.com/watch?v=k8EURBL53_k https://www.youtube.com/watch?v=k8EURBL53_k
- red_admiral 2mo ago
  IBM briefly pulled ahead with the PC though, mainly by routing around their own bureaucracy. That was a hard innovation problem, especially without a crystal ball.
- torginus 2mo ago
positron26 2mo ago
Lol. In 2015 boring technology is at the hands of your PM spinning up some agent spam. Bury this pile of outdated thinking. Go hard at the most difficult programming you can find or go home.
gaigalas 2mo ago
Go hard boring on 80% of what you do. Go hard exciting on the 20% else. Don't let one affect the other.
jcmontx 2mo ago
Excellent post. Now, somewhat outdated, and in other ways, more relevant than ever. To whom it may concern: if you need a database, always choose postgresql.
iand675 2mo ago
Well, I've not tried to publish this on HN so far, but I guess given such a counterpoint, I should at least attempt to share: https://www.iankduncan.com/engineering/2026-08-07-getting-freaky-in-the-age-of-ai https://www.iankduncan.com/engineering/2026-08-07-getting-fr...
- __MatrixMan__ 2mo ago
  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.
  - rienbdj 2mo ago
    It’s easier to imagine a super power than the end of capitalism, apparently.
    - inigyou 2mo ago
      It's famously easier to imagine the end of the world than the end of capitalism.
  - jonahx 2mo ago
    > 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. That is tragically sad.
    - dylan604 2mo ago
      It's better than saying invisibility as that always leads to someone being creepy. Laser beam eyes is of limited use. Moving through walls seems kind of meh to me as that's not a really limiting factor in my day to day. Shooting webs from my writs maybe kind of cool, but if its main use is for moving around it is much more limited than just being able to fly. Lasso of truth isn't really a super power but an interesting artifact. Of all of the super powers, the ability to fly does feel the most utilitarian to me. Plus, think of how environmentally friendly that super power would be if everyone could do it
piterrro 2mo ago
https://grugbrain.dev/ https://grugbrain.dev/ Similar on this topic
clueless 2mo ago
I remember reading this back in 2015, but how is this not just the age old conservative (don't do more than needed) vs progressives (lets try some new risk things) debate? As much as I can relate to a more conservative choice when choosing tech that might power a giant consumer company, sometimes using riskier tech in a startup makes more sense to get the real innovation flowing... and the idea of "Choose New Technology, Sometimes" just feels like a little cheat to get away from the bigger issue with the overall thesis. In this way, the idea in this blog just feels so out of touch.
- t-writescode 2mo ago
  It’s not about conservative vs progressive but about “safe, battle-tested, stable” vs “could be amazing future-tech”; and the idea of having a small number of innovative technologies, in particular where they matter, is about allowing yourself to spend all those thought-tokens on areas that matter. 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.
  - clueless 2mo ago
    I might be missing something but conceptually, “safe, battle-tested, stable” vs “could be amazing future-tech” IS about conservative vs progressive... am I missing something?
    - t-writescode 2mo ago
      Good point, I suppose conservative is the right word there. Its broader meaning has been a bit louder lately, so I didn’t think of it the right way there.
  - deleted 2mo ago
    [deleted]
- nonameiguess 2mo ago
  I feel like there's a common theme in business advice like this, the bullshit jobs thesis, general alienation of workers, that individuals have a lot of tunnel vision and don't understand the place of a firm in capitalism. The reality is we don't know what strategies will and won't succeed. The system overall works to the extent it works because a hundred thousand monkeys throwing shit at the wall are bound to hit a few targets at least a few times, even if the vast majority of them miss. The larger economy and investment ecosystems are set up under the assumption that most products will never see a single user and most companies will fail. Most employees will spend much of their careers working on projects that get scrapped. It's not much different than life itself. Evolution has no master plan. Most organisms never reproduce. Most species barely make a blip in any ecosystem before going extinct. It sucks for the individuals, but the larger collective goes on and thrives. Life itself does fine. The economy at large does fine, in spite of the ebbs and flows of the business cycle with its bubbles and recessions. Everything still works out in the long run. It's not only okay to fail but it's crucial to the long run success of our collective endeavors. 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.
tetrisgm 2mo ago
The title reminds me of Gunpei Yokoi, the original genius designer at Nintendo, whose philosophy was: lateral thinking, with old technology
mr_toad 2mo ago
Does nobody ever think of trying more than one technology? It’s like people buying a car based on what everyone else is driving rather than actually driving different cars.
- voiper1 2mo ago
  Only do one new thing at a time. 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.
- grebc 2mo ago
  Good question. Highly likely to not get any other replies as it’s too much uncommon sense.
- Cthulhu_ 2mo ago
  Sure, that's what the POC stage of choosing technology is about if you can't make a decision on blurbs on websites or comparison tables.
- interf4ce 2mo ago
  I think you're conflating general "boringness" with tech-specific features. Test driving solutions is useful but it tells you nothing about reliability. 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.
wewewedxfgdf 2mo ago
Counter-position: "choose most appropriate technology".
- interf4ce 2mo ago
  Choosing the most appropriate tech is not mutually exclusive with choosing boring tech. In fact, "boring" (well-known, battle-tested) is very likely the most appropriate because it reduces unnecessary risk.
- Cthulhu_ 2mo ago
  It really depends, there are a lot of axes to consider. When the most appropriate technology is e.g. a programming language that less than 1% of developers on the market can write competently, would you risk the company on it?
rienbdj 2mo ago
This blog post annoys me a little. Not the post itself - it’s great - but how it has been used to prop up thousands of lazy arguments against innovations over the years.
pianopatrick 2mo ago
One theory these days might be that old, boring technology is better represented in the training data for AI models...
twotwigs 2mo ago
[dead]
- deleted 2mo ago
  [deleted]
saadyousfi 2mo ago
[dead]
Krei-se 2mo ago
PHP is boring - but it works.
bakoserge 2mo ago
[flagged]
sleight42 2mo ago
This isn't new. 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".
- Nextgrid 2mo ago
  Not fucking with a thing that works as desired would put a large chunk of the tech industry out of a job.
jason_oster 2mo ago
This advice holds up, but there are caveats to keep in mind. Two off the top of my head: 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.
wewewedxfgdf 2mo ago
This is a generalization. And generalizations in software development are always wrong.
cliche 2mo ago
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
- eudamoniac 2mo ago
  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.
  - zahlman 2mo ago
    Last I checked, Java was still more popular than C# (for reasons I can't comprehend).
    - eudamoniac 2mo ago
      Most companies are boring and conservative in tech. Just not most "tech companies".
  - Maxion 2mo ago
    Same with Python/Django/DRF
  - cliche 2mo ago
    That’s a good shout I miss ruby / rails
threethirtytwo 2mo ago
This is a stupid single minded philosophy. What if the new non-boring technology has an exclusive feature you need? What if it's genuinely better? 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.
jobuildsstuff 2mo ago
[flagged]
fenestella 2mo ago
[dead]
smolder 2mo ago
Boring technology is great for making things in certain niches. This argument gets used a lot to encourage Java for every purpose, which comes from a myopic view of the landscape of languages. Advocates of many languages use the "least effort with biggest result" claim, and it's out of ignorance.
kimonsodu 2mo ago
[dead]
dexterlagan 2mo ago
Can confirm. Use boring, proven tech at work. Experiment at home, on your own time. Using 'exciting' and new tech is fun but brings risks that are often unacceptable. If the tech dies, you have just created a pile of debt for your business, and potentially years of difficult maintenance and possibly a rewrite ahead. Don't.
gdiamos 2mo ago
In hindsight I disagree. 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.
- red_admiral 2mo ago
  Innovation or research, maybe. Keeping an enterprise system running and maintainable is the opposite problem.
  - gdiamos 2mo ago
    There's certainly a place for enterprise and not breaking what's working. Shouldn't that be 0 innovation tokens though?
benrutter 2mo ago
This is a great article, I feel like I think of this a lot when I build something new. 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.
- Cthulhu_ 2mo ago
  This is where 'boringness' is only one factor in the bigger equation, and you (as a team) should make a list of criteria - familiarity, features, cost, hiring, support/backing, etc.
everyone 2mo ago
imo only webdevs would ever need to say something like this.. It seemed to me that webdev was so trivial that webdevs became eccentrics and invented all sorts of wacky frameworks and languages just to make their work challenging and interesting.
lloydatkinson 2mo ago
The "content not viewable in your region" images really sets the tone.
red_admiral 2mo ago
Golang was supposed to be boring by design (https://go.dev/talks/2012/splash.article https://go.dev/talks/2012/splash.article) and you can use it in a boring way. Even learning golang is relatively boring.
- Cthulhu_ 2mo ago
  Go the language and Go the ecosystem seem to be the antithesis of languages like Scala that seems to be a form of self-gratification when used to solve boring problems like HTTP APIs, or ecosystems like Javascript's where all the tools are rewritten into something faster and better in recent years.
lilerjee 2mo ago
I have the similar opinions: 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.
Studui81Labs 2mo ago
[flagged]
waldarbeiter 2mo ago
Not to bring LLMs into everything but I think they make using boring stuff more likely. Since training data contains a lot of it and less of the shiny new stuff.
- leecommamichael 2mo ago
  I wish LLMs were more boring.
willejs 2mo ago
This is one of my favourite blogposts and then presentations https://boringtechnology.club/ https://boringtechnology.club/... Back when it first came out, everyone was rushing to build microservices and shun practiced technologies, systems and software architectures, in search of some shortcut to software and systems utopia. 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.
- jmartrican 2mo ago
  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
  - dnautics 2mo ago
    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 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
    - willejs 2mo ago
      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...
jmartrican 2mo ago
Now boring tech is what is well known by the LLM (Python, typscript, etc.).
thelastgallon 2mo ago
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, 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.
- altern8 2mo ago
  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.
  - tpmoney 2mo ago
    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.
- silvestrov 2mo ago
  In the old days 25 years ago, x86 hardware was the main source of unreliability. Today x86 hardware is super reliable and unneeded complexity in the software stack is the main source of problems.
gwbas1c 2mo ago
Regarding "Optimize Globally" 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.)
davnicwil 2mo ago
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 more importantly, maintain and operate) and was really all we needed for most useful business software.
- k__ 2mo ago
  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.
  - davnicwil 2mo ago
    [dead]

438 points by tosh 2mo ago

Software that works year-after-year has never been a commodity. It's boring on the surface. It doesn't get the flashy posts. But I'll choose reliable over new in almost all cases.

jay_kyburz 2mo ago
This is why it took me so long before giving Go a try, even though on paper it sounds exactly what I want from a language. I'm glad I finally did, I've been enjoying it.

NickNaraghi 2mo ago

> Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. 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.

nomel 2mo ago
There was another, much older, post similar to this about, I think, "beans" that engineers use to solve problems. If I remember correctly, it was something like, solving a problem costs "beans", and engineers will always use most all of their "beans" to solve a given problem, because it's somewhat "easy" until you run out of them. Maybe it wasn't beans? But, I've been looking for it for years.
- PyWoody 2mo ago
  Not what you're after, but your talk of beans reminded me of Taco Bell Programming. [0] [0] https://widgetsandshit.com/teddziuba/2010/10/taco-bell-programming.html https://widgetsandshit.com/teddziuba/2010/10/taco-bell-progr...
  - krapht 2mo ago
    His example of a web crawler stinks. I can get behind the philosophy, but his specific web crawler example at a minimum needs to retry, respect robots.txt, and rate limit per domain. So no, xargs + curl is a dumb example.
    - nimih 2mo ago
      Based on bot traffic to my personal blog over the past year or so, the minimum viable web crawler apparently does not need any of those things (much to my own personal annoyance, to be very clear).
    - nine_k 2mo ago
      Replace curl with wget, get robots.txt support. Write timed-out URLs into a file for the next identical run. 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.
    - groundzeros2015 2mo ago
      Nah. It’s fine.
  - ChrisMarshallNY 2mo ago
    Speaking of beans, here's a classic (totally different from the main topic. Welcome to Topic Creep): https://archive.uie.com/brainsparks/2011/07/08/beans-and-noses/ https://archive.uie.com/brainsparks/2011/07/08/beans-and-nos...
    - asalahli 2mo ago
      This was a great read, thanks! I've naively tried to stop too many beans-and-noses situations in the past.
- cwnyth 2mo ago
  This is where efficiency can be applied in two distinct ways. On the one hand, if using more beans means you can solve the problem more quickly, then it is more efficient to the problem solver to do so. 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.
- contingencies 2mo ago
  You misspelled 'beers'. A boring technology.
- bch 2mo ago
  I’m vaguely recalling something - and I think the beans might’ve also represented vetos, so one had a limited number of objections to other people’s ideas… quick search revealing nothing so far, though.
  - nomel 2mo ago
    Sounds familiar! I believe it was a simple html page hosted on some university user page. 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.
thewakalix 2mo ago
"Weirdness points" are similar: https://www.lesswrong.com/w/weirdness-points https://www.lesswrong.com/w/weirdness-points
tshaddox 2mo ago
I like the general concept, but I think framing it as a small number of discrete tokens isn't quite right. I'd treat the whole thing in terms of debt and risk. Using "non-boring" technology [0] is really just subtracting some amount from your balance. You don't want your balance to go too negative, but carrying some debt is sometimes fine. And some risky bets might turn out to have a huge ROI! 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."
- sgarland 2mo ago
  From TFA: “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.
eudamoniac 2mo ago
I think the same way about any personal project. You can either make something unfamiliar, or make it with unfamiliar technology stack, but you shouldn't do both.
monk_grilla 2mo ago
I also broadly agree with the post. > 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.
- williamcotton 2mo ago
  It’s pretty boring at this point.
- sgarland 2mo ago
  I think calling anything in the JavaScript ecosystem “mature” is a bit of a stretch. This is the same community that brought us left-pad.
  - lkirkwood 2mo ago
    10 years ago though
    - mikestorrent 2mo ago
      And here we are, almost all the complaints from a decade ago still have relevance
    - Cthulhu_ 2mo ago
      Some wounds never heal. Like Angular 1->2.
  - samtheprogram 2mo ago
    That's an insane take. Anything?!?
    - anon48293 2mo ago
      Can you name a single thing in the JavaScript ecosystem which has been stable for 10 years?
Cthulhu_ 2mo ago
I think a core problem is that people read online and spend a weekend looking into something cool and get a pretty decent POC up and running. But that's a single person in a weekend, nowadays accellerated by LLMs - what they cannot see (or, something that comes with experience) is how expensive or invasive it would be to apply that in your team or company-wide. 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.

tosh 2mo ago

aged well

mewens 2mo ago

[flagged]

moresVanpersi 2mo ago

[dead]

conrs 2mo ago

Love this post. Surprisingly controversial; it hasn't made me very many engineering friends.

andai 2mo ago
It's bad for building your resume. Managers and employees are rewarded for popular thing. Popularity is mostly a function of novelty. So the (social and therefore economic) incentive structure is inversely correlated with choosing boring technology.
- abirch 2mo ago
  I see it as analogous to people are frequently rewarded for putting out the fire instead of preventing the fire.
  - andai 2mo ago
    I've been noticing this as a solo dev. I need to put lots of work into infra and security, and all I get for it is... the thing not blowing up (hopefully!). The work is invisible, and impossible to "show off", so it's a bit unrewarding and demoralizing. But hey, someone needs to do it!
    - Cthulhu_ 2mo ago
      And the worst part is, because it's invisible, a higher up manager will think "Ah, we don't need these people anymore, let's replace them with juniors, an external company, and/or AI". It's maddening. 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').
  - Cthulhu_ 2mo ago
    Exactly. When I joined the company I'm at now (consumer energy industry), the energy crisis hit and the servers melted from all the people looking to fix their contracts etc. I wasn't directly involved, but loads of developers did a mammoth effort to rewrite old services to prevent this from ever happening again. 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.

theptip 2mo ago

I love this post. It’s also interesting to revisit in the age of agents. 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.)

epolanski 2mo ago
One thing I learned about AI is that, e.g., if you're making websites you're much better off going for php/ruby/elixir, even if you don't like the languages much. 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.
- add-sub-mul-div 2mo ago
  The willingness to reshape society for the benefit of AI rather than shaping AI around humanity paints a very dire picture of the coming decade.
  - epolanski 2mo ago
    I think you're completely misreading what I wrote. 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.

dofm 2mo ago

A problem shared is a problem halved.

tosh 2mo ago

now 11y later i wonder if 'node.js' still needs an innovation token or not

esafak 2mo ago
Do you mean alternatives, like Bun and Deno, or a future direction for itself? edit: Node is boring, as far as the frontend goes -- a notoriously unstable ecosystem.
- xboxnolifes 2mo ago
  They mean as the article describes. Does using node require using an innovation token.
wmf 2mo ago
Node.js has been boring for a while.

martythemaniak 2mo ago

The problem with this is that the list of tech that gets boring changes all time, faster than people's opinions. Kubernetes is very boring tech, but if you go through the old discussion threads on this (even from the last year or two), Kubernetes is still cited as some brand new wizbang thing you shouldn't spend tokens on.

leetrout 2mo ago
Over 12 years of popular usage at this point. I still think it's inappropriate for ~90% of the companies using it.
- rzerowan 2mo ago
  Ideally a techthat is not core to the business goals should neither occupy dev/ops time managing it or be so complex that its failure modes are cryptic. It should get out of the devs way and be easy to grok in case of failures.
- asa400 2mo ago
  Apologies in advance this turned in to a bit of a rant of violent agreement. 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.

insanitybit 2mo ago

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

bcrosby95 2mo ago
This was written over a decade ago. I'd take it in that context. Lots of the tech they're talking about was being cargo culted en-masse. So yes, pick boring tech, defined as the tech you know the sharp edges of.
- insanitybit 2mo ago
  I don't think that context is relevant to my comment. I didn't say "in hindsight, those technologies are great!", I pointed out that "boring" is meaningless, and any meaning you attribute to it like "defined as the tech you know the sharp edges of" is better substituted in. 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.

dwedge 2mo ago

I read a similar blog post years ago about restricting the technologies you use, and making do with a slightly worse option if it means reusing the stack you already have. 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?

deleted 2mo ago
[deleted]
simonw 2mo ago
Pretty sure it was this one linked in the OP. See this footnote: https://mcfunley.com/choose-boring-technology#f4 https://mcfunley.com/choose-boring-technology#f4 > 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.
- dwedge 2mo ago
  I can't believe I was asking about the same article. The flow of time made it feel different and I forgot this was one of my all time favourites that I've been trying to re-find for years. Thank you

exabrial 2mo ago

nawh. 50x node modules, typescript out the wazoo, all the state in the client (where you can't see it in prod), the most over-complicated UI, paired with async callback spaghetti is what you do these days. We're "scalable" over here. It's a sexy problem to have.

westoque 2mo ago

i just did an AI hackathon and 90% of the submissions were written in TypeScript and Next.js which is mostly due to the training data. AI is skewed to use these tools by default vs the best for the job.

geophile 2mo ago

Think inside the box! Sadly, that is real out-of-the-box thinking.

Animats 2mo ago

Some of this may have been a reaction to the era of Javascript framework churn. There were way too many different technologies for doing roughly the same job. They all more or less worked. 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 https://www.youtube.com/watch?v=vKQYG_fA2uM [2] https://www.youtube.com/watch?v=l1-urTRxeEM https://www.youtube.com/watch?v=l1-urTRxeEM [3] https://en.wikipedia.org/wiki/Coffin_corner_%28aerodynamics%29 https://en.wikipedia.org/wiki/Coffin_corner_%28aerodynamics%... [4] https://www.youtube.com/watch?v=k8EURBL53_k https://www.youtube.com/watch?v=k8EURBL53_k

red_admiral 2mo ago
IBM briefly pulled ahead with the PC though, mainly by routing around their own bureaucracy. That was a hard innovation problem, especially without a crystal ball.
torginus 2mo ago

positron26 2mo ago

Lol. In 2015 boring technology is at the hands of your PM spinning up some agent spam. Bury this pile of outdated thinking. Go hard at the most difficult programming you can find or go home.

gaigalas 2mo ago

Go hard boring on 80% of what you do. Go hard exciting on the 20% else. Don't let one affect the other.

jcmontx 2mo ago

Excellent post. Now, somewhat outdated, and in other ways, more relevant than ever. To whom it may concern: if you need a database, always choose postgresql.

iand675 2mo ago

Well, I've not tried to publish this on HN so far, but I guess given such a counterpoint, I should at least attempt to share: https://www.iankduncan.com/engineering/2026-08-07-getting-freaky-in-the-age-of-ai https://www.iankduncan.com/engineering/2026-08-07-getting-fr...

__MatrixMan__ 2mo ago
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.
- rienbdj 2mo ago
  It’s easier to imagine a super power than the end of capitalism, apparently.
  - inigyou 2mo ago
    It's famously easier to imagine the end of the world than the end of capitalism.
- jonahx 2mo ago
  > 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. That is tragically sad.
  - dylan604 2mo ago
    It's better than saying invisibility as that always leads to someone being creepy. Laser beam eyes is of limited use. Moving through walls seems kind of meh to me as that's not a really limiting factor in my day to day. Shooting webs from my writs maybe kind of cool, but if its main use is for moving around it is much more limited than just being able to fly. Lasso of truth isn't really a super power but an interesting artifact. Of all of the super powers, the ability to fly does feel the most utilitarian to me. Plus, think of how environmentally friendly that super power would be if everyone could do it

piterrro 2mo ago

https://grugbrain.dev/ https://grugbrain.dev/ Similar on this topic

clueless 2mo ago

I remember reading this back in 2015, but how is this not just the age old conservative (don't do more than needed) vs progressives (lets try some new risk things) debate? As much as I can relate to a more conservative choice when choosing tech that might power a giant consumer company, sometimes using riskier tech in a startup makes more sense to get the real innovation flowing... and the idea of "Choose New Technology, Sometimes" just feels like a little cheat to get away from the bigger issue with the overall thesis. In this way, the idea in this blog just feels so out of touch.

t-writescode 2mo ago
It’s not about conservative vs progressive but about “safe, battle-tested, stable” vs “could be amazing future-tech”; and the idea of having a small number of innovative technologies, in particular where they matter, is about allowing yourself to spend all those thought-tokens on areas that matter. 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.
- clueless 2mo ago
  I might be missing something but conceptually, “safe, battle-tested, stable” vs “could be amazing future-tech” IS about conservative vs progressive... am I missing something?
  - t-writescode 2mo ago
    Good point, I suppose conservative is the right word there. Its broader meaning has been a bit louder lately, so I didn’t think of it the right way there.
- deleted 2mo ago
  [deleted]
nonameiguess 2mo ago
I feel like there's a common theme in business advice like this, the bullshit jobs thesis, general alienation of workers, that individuals have a lot of tunnel vision and don't understand the place of a firm in capitalism. The reality is we don't know what strategies will and won't succeed. The system overall works to the extent it works because a hundred thousand monkeys throwing shit at the wall are bound to hit a few targets at least a few times, even if the vast majority of them miss. The larger economy and investment ecosystems are set up under the assumption that most products will never see a single user and most companies will fail. Most employees will spend much of their careers working on projects that get scrapped. It's not much different than life itself. Evolution has no master plan. Most organisms never reproduce. Most species barely make a blip in any ecosystem before going extinct. It sucks for the individuals, but the larger collective goes on and thrives. Life itself does fine. The economy at large does fine, in spite of the ebbs and flows of the business cycle with its bubbles and recessions. Everything still works out in the long run. It's not only okay to fail but it's crucial to the long run success of our collective endeavors. 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.

tetrisgm 2mo ago

The title reminds me of Gunpei Yokoi, the original genius designer at Nintendo, whose philosophy was: lateral thinking, with old technology

mr_toad 2mo ago

Does nobody ever think of trying more than one technology? It’s like people buying a car based on what everyone else is driving rather than actually driving different cars.

voiper1 2mo ago
Only do one new thing at a time. 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.
grebc 2mo ago
Good question. Highly likely to not get any other replies as it’s too much uncommon sense.
Cthulhu_ 2mo ago
Sure, that's what the POC stage of choosing technology is about if you can't make a decision on blurbs on websites or comparison tables.
interf4ce 2mo ago
I think you're conflating general "boringness" with tech-specific features. Test driving solutions is useful but it tells you nothing about reliability. 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.

wewewedxfgdf 2mo ago

Counter-position: "choose most appropriate technology".

interf4ce 2mo ago
Choosing the most appropriate tech is not mutually exclusive with choosing boring tech. In fact, "boring" (well-known, battle-tested) is very likely the most appropriate because it reduces unnecessary risk.
Cthulhu_ 2mo ago
It really depends, there are a lot of axes to consider. When the most appropriate technology is e.g. a programming language that less than 1% of developers on the market can write competently, would you risk the company on it?

rienbdj 2mo ago

This blog post annoys me a little. Not the post itself - it’s great - but how it has been used to prop up thousands of lazy arguments against innovations over the years.

pianopatrick 2mo ago

One theory these days might be that old, boring technology is better represented in the training data for AI models...

twotwigs 2mo ago

[dead]

deleted 2mo ago
[deleted]

saadyousfi 2mo ago

[dead]

Krei-se 2mo ago

PHP is boring - but it works.

bakoserge 2mo ago

[flagged]

sleight42 2mo ago

This isn't new. 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".

Nextgrid 2mo ago
Not fucking with a thing that works as desired would put a large chunk of the tech industry out of a job.

jason_oster 2mo ago

This advice holds up, but there are caveats to keep in mind. Two off the top of my head: 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.

wewewedxfgdf 2mo ago

This is a generalization. And generalizations in software development are always wrong.

cliche 2mo ago

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

eudamoniac 2mo ago
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.
- zahlman 2mo ago
  Last I checked, Java was still more popular than C# (for reasons I can't comprehend).
  - eudamoniac 2mo ago
    Most companies are boring and conservative in tech. Just not most "tech companies".
- Maxion 2mo ago
  Same with Python/Django/DRF
- cliche 2mo ago
  That’s a good shout I miss ruby / rails

threethirtytwo 2mo ago

This is a stupid single minded philosophy. What if the new non-boring technology has an exclusive feature you need? What if it's genuinely better? 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.

jobuildsstuff 2mo ago

[flagged]

fenestella 2mo ago

[dead]

smolder 2mo ago

Boring technology is great for making things in certain niches. This argument gets used a lot to encourage Java for every purpose, which comes from a myopic view of the landscape of languages. Advocates of many languages use the "least effort with biggest result" claim, and it's out of ignorance.

kimonsodu 2mo ago

[dead]

dexterlagan 2mo ago

Can confirm. Use boring, proven tech at work. Experiment at home, on your own time. Using 'exciting' and new tech is fun but brings risks that are often unacceptable. If the tech dies, you have just created a pile of debt for your business, and potentially years of difficult maintenance and possibly a rewrite ahead. Don't.

gdiamos 2mo ago

In hindsight I disagree. 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.

red_admiral 2mo ago
Innovation or research, maybe. Keeping an enterprise system running and maintainable is the opposite problem.
- gdiamos 2mo ago
  There's certainly a place for enterprise and not breaking what's working. Shouldn't that be 0 innovation tokens though?

benrutter 2mo ago

This is a great article, I feel like I think of this a lot when I build something new. 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.

Cthulhu_ 2mo ago
This is where 'boringness' is only one factor in the bigger equation, and you (as a team) should make a list of criteria - familiarity, features, cost, hiring, support/backing, etc.

everyone 2mo ago

imo only webdevs would ever need to say something like this.. It seemed to me that webdev was so trivial that webdevs became eccentrics and invented all sorts of wacky frameworks and languages just to make their work challenging and interesting.

lloydatkinson 2mo ago

The "content not viewable in your region" images really sets the tone.

red_admiral 2mo ago

Golang was supposed to be boring by design (https://go.dev/talks/2012/splash.article https://go.dev/talks/2012/splash.article) and you can use it in a boring way. Even learning golang is relatively boring.

Cthulhu_ 2mo ago
Go the language and Go the ecosystem seem to be the antithesis of languages like Scala that seems to be a form of self-gratification when used to solve boring problems like HTTP APIs, or ecosystems like Javascript's where all the tools are rewritten into something faster and better in recent years.

lilerjee 2mo ago

I have the similar opinions: 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.

Studui81Labs 2mo ago

[flagged]

waldarbeiter 2mo ago

Not to bring LLMs into everything but I think they make using boring stuff more likely. Since training data contains a lot of it and less of the shiny new stuff.

leecommamichael 2mo ago
I wish LLMs were more boring.

willejs 2mo ago

This is one of my favourite blogposts and then presentations https://boringtechnology.club/ https://boringtechnology.club/... Back when it first came out, everyone was rushing to build microservices and shun practiced technologies, systems and software architectures, in search of some shortcut to software and systems utopia. 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.

jmartrican 2mo ago
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
- dnautics 2mo ago
  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 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
  - willejs 2mo ago
    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...

jmartrican 2mo ago

Now boring tech is what is well known by the LLM (Python, typscript, etc.).

thelastgallon 2mo ago

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

altern8 2mo ago
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.
- tpmoney 2mo ago
  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.
silvestrov 2mo ago
In the old days 25 years ago, x86 hardware was the main source of unreliability. Today x86 hardware is super reliable and unneeded complexity in the software stack is the main source of problems.

gwbas1c 2mo ago

Regarding "Optimize Globally" 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.)

davnicwil 2mo ago

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 more importantly, maintain and operate) and was really all we needed for most useful business software.

k__ 2mo ago
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.
- davnicwil 2mo ago
  [dead]