IMHO boring tech is great because it lets you focus on the actual tech of your product. I run a SaaS app and I'd like to think we do alot of cutting edge things in various places, as it relates to the actual product. For things that are "behind the scenes" like databases, backend fraemworks, etc, etc, I prefer to keep all that stuff as boring and as stable as possible. For me working solo on a project, my time is very limited. So I would much rather work on interesting new features for my product than having to touch crap that my customers don't care about. Because at the end of the day my customers don't know and don't care that I use Node vs Deno or Bun, or that I use NPM instead of pnpm, or that I'm not on the latest version of node or Postgres. They don't know all that but they do know how well my app works or what features it has.
I see your point here, but I want represent a counterpoint to this line of reasoning, from my personal experience. I've been in a lot of situations where someone simply wants their way--in this case they want the organization to choose their personal software preference--and so they call it the "boring" choice.
By calling it boring, they characterize their _preference_ as the majority accepted, mature, obvious decision and anything else is merely software engineers chasing shiny objects. The truth is almost always more nuanced. Both solutions have pros and cons. They trade-off different values that resonate more or less with different people.
So, please be careful with the "it's boring and therefore obviously better" argument. Don't let it be a way to summarily dismiss someone else's preferences in favor of your own--without a deeper discussion of trade-offs. Otherwise it's no better than any other condescending attempt (ex. I'm in charge, so we are doing it this way. No one ever got fired choosing IBM/Microsoft/..) to win an argument without having to present real arguments.
> be careful with the "it's boring and therefore obviously better" argument
The same way I would say be wary an argument which can be boiled down to "it's newer so it's obviously better". I used to made such argument myself in the beginning of my career but now I see that proffering everything new is a bad strategy.
Comparing software objectively is hard (if not impossible), and there is a place for personal presences too. But if after a discussion of pros and cons it's not obvious which of two options is significantly better I would be inclined to choose an older and more established technology.
Demagogy is MUCH better than real arguments. Most people you work with will have trouble even understanding the latter. They don't have time, they're overloaded, their kids are waiting at home. Give them the warm feeling that they're doing the right thing. Make them feel smart, experienced,
elite. That's how you get support, not by appealing to (ugh) reason.
I think people are just tired of arguing with people who think you need, say, an entire cluster orchestration system, and a renderer inside your renderer just to serve up some web pages. It's a lot easier to just tell people to use "boring technology". The ones who get it, get it.
I would only add "stable" to what "boring" tech is. Notably, though, not "stable" as in "doesn't crash." But more as in "doesn't change."
I think you typically see this with older, established, things. But there is nothing guaranteeing it. And, indeed, it is often the result of specific action on the stewards of a technology.
This can often be couched in terms of backwards compatibility. Which is a clear action one can pursue to get stability. However, it can also be seen in greatly limiting scope. As an example, we love talking about scale, but that doesn't mean you have to design and build for scale you will never see.
The eternal discussion isn't about old vs new or boring vs exciting. Mature is mature regardless of age.
A system that breaks when updating dependencies, introduces unexpected behaviour through obscure defaults, forces you to navigate layers of abstraction isn't mature... (looking at you Spring and Java ecosystem), it's old and unstable.
Stability, predictability, and well-designed simplicity define maturity, not age alone.
Is Python mature and boring? With toolchain issues and headaches of all kinds... Newer languages like Go or Rust i.e solve all these toolchain issues and make it truly boring in the best way possible.
I think it’s hard to tell with the signals we have on GitHub for example the difference between mature and dead as a project. Regardless of what a commit is for, it’s a sign that someone is watching and maintaining and any novel issue will likely be quickly addressed. I think this means new stuff always will have an advantage there.
The age of last commit on trunk is a useless metric in isolation. The fact that it is the most prominent number on the front page of a repository is a shame.
I wish we could just let software "die" aka be stable without constant updates. For software that doesn't have a significant attack surface (security) it'd be amazing. But because of the bitrot of constantly changing underlying APIs and platforms, oftentimes if you find some Python script that hasn't been updated for a few years it'll already be broken in some horrible ways due to dependencies changing and no longer being compatible with current versions of certain libraries.
Think of how much time is wasted because so much software that's been written but not maintained and can't be used because of how libraries have "evolved" since then.
If you’re just glancing, then sure… and maybe if it’s only glancing-level important then that’s fine.
In my experience there are almost always some issues (either legit or misguided support requests,) PRs for docs and features, updates to libraries for vulnerabilities or deprecated code. Worth looking at stuff that isn’t open also. Even if it’s a 10 year old project and the last commit is from 6 months ago fixing a seemingly minor bug, if there more than a few stars or forks, and there aren’t ignored issues and PRs sitting there, I’d consider it trustworthy.
And if it does look abandoned but was active at some point, it’s always a good idea to take a stroll through the forks.
I don't have anything of note publicly out there, if I did and it was still a going concern despite having had no updates for quite some time (so “fished and stable” rather than “dead and not to be relied upon unless you want to maintain it yourself”), I'd chuck a commit in every now and then (annually? every six months?) if only to update the readme.md to say that as of <current date> I didn't consider the project any less supported than it was at the point of the previous update.
in open source, there are no 'dead projects'. maybe just abandoned
but if you find a mature/dead project there's a chance it's just old and stable.
what I'm getting at is in an unmantained project any stranger should be able to figure out how to adrees any novel issues. it's the point of open source; I don't undrestand why this is failing. maybe beacuse understanding an anonymous code base is hard work?
Yeah, sometimes people on HN make this assumption in the other direction, insisting that such-and-such a project is surely very mature (with a very quiet userbase) and not dead, on account of it not having any recent updates. But sometimes projects are truly just dead and buried. E.g., the million old frameworks and libraries that haven't been touched since 2005 and haven't had a functioning website since 2015. Bonus points if the only downloads were hosted on a SourceForge clone that also no longer exists outside the Internet Archive.
It's sometimes possible for a project to have 0 bugs to fix and 0 in-scope improvements (for performance, compatibility, etc.) left to make, but only if its scope is extremely limited. Even Knuth still gets bug reports for his age-old TeX.
I found it useful to read through the open and closed issues and estimate what caused the described problems. Look at the usecases that do not work, are they common or exotic? Does the program fail safely or does it fall back to unwanted behavior? Does a certain configuration cause the program to run amok and wipe your disk?
If you get many "wtf" moments while doing this, the project is not mature.
Nobody ever got a promotion, or hired, by using boring tech.
I have a feeling that I don't get many replies to job applications because the vast majority of work I've done is "boring", and the majority of open source code I've written is shell scripts. It all works fantastic, and has zero bugs and maintenance cost, but it's not sexy. Intellectual elitism has also defined my role ("DevOps Engineer" is literally just a "Sysadmin in the cloud", but we can't say that because we're supposed to be embarrassed to administrate systems); I'm fairly confident if my resume was more "Go and Rust" than "Python and Shell", I'd get hired in a heartbeat.
Boring is great as long as you aren't looking for a job. There is a significant risk that you are slowly removing yourself from the job market if you stick to boring tech. Your next employer often doesn't give a sh.t that you provided great business value. Most of them want shiny new. When I read the ads of my current employer I don't think I would get hired.
Java, .NET/C#, C++, server side frameworks like Spring and ASP.NET, vanila.js when the option is on me, WinForms/WPF/Swing/Qt, Visual Studio, Eclipse/Netbeans.
The Python 2-3 transition and some developments after made it definitely not so boring for me, but hopefully it'll be more stable in the coming decades ;).
"Cannot live without" is a strong wording, but software that I use a lot and that's mature/stable in my experience: shell (zsh, bash, sh), GNU utils, vim, nmap, xfce, git, ssh, mpv, Xorg, curl, and lots of little old CLI tools.
Emacs. 20 years and all that time I wished I could get rid of it, but every other editor/IDE I've tried lacks a feature (or ten).
Debian. Moves at its own pace, flexible yet stable enough to cope with my idea of a smart move.
Go. I've been playing with it since before 1.0, threw it into production at my first occasion, and all those years it continues to deliver.
Django. Identical story.
...StarCraft (1, then 2). Technically not "tech", but in a competitive setting, it remains strategically, tactically, and mechanically demanding, it reflects that path of mastery, "teach yourself programming in ten years". It shaped my spirit, attitude, but also humility.
I work largely in the JS ecosystem so for me it would be Express. Everyone says the Express project is dead because they hardly ever update it but IMHO the real reason they never update it is it's been practically perfected.
Express has so many different uses and I've used it on very large scale backend projects for Fortune 500's, shoved it inside lambda functions, and used it to host email templates and build dev tooling with it to overcome shitty API's at work that always go down.
In all those times I don't think I've ever run into an issue that wasn't already solved
If the benefits of the newer tech outweigh its risks you use it. The challenge is weighing the evidence. Newer technologies will tout their advantages, but the disadvantages are not advertised as loudly, and are often uncovered after making the investment. "Boring" or "exciting" is the wrong framing.
Boring tech is really better described as extremely late adopter strategy.
Maybe it makes sense for your business maybe it doesn't. If you don't want to be on the forefront of technology, well don't. I don't think that launching every startup using the late adopter strategy is necessarily going to result in better business performance. Those that find a better way to do things will win.
I agree with this article, but with one caveat. Don't be the guy that becomes the designated INSERT_OLD_TECH_HERE guy in the office while the rest of the team is working with the cool modern tech that has a lot of jobs in the market, don't pigeon your career by becoming an expert in legacy tech, like COBOL, RPGLE or FORTRAN. You'll find yourself in a position where you'll get fired and won't be able to find another job because there aren't many jobs for your skills and because companies only want to hire people with years of experience in the tech they're using, be it javascript, java, go etc.
And also these legacy techs don't pay that much in general, for every consultant making bank fixing COBOL bugs there are probably dozens or more COBOL developer making less than a javascript developer, so you'll find yourself making less money than a kid with a 3 years of experience in web development, and when you go out in the market trying to switch jobs, you'll have a hard time finding a new job or salaries will suck. Don't be stupid and become the fall guy to keep the legacy debt going while everybody else in the company is learning the in-demand cool stuff and padding their resumes with hire able skills. You will regret it.
This is a great point. I think there's a balance between "OOH, shiny new thing" and "kids these days". It always pays to play with new tech or otherwise learn about it. Both for you the developer (who avoids getting pigeon holed) and for the business (because there may be new capabilities or cost savings).
But introducing it willy nilly into production applications because you want to gain experience with it is bad. Bad for the business, at least. For you it might be resume driven development.
That's why I always advocate for time and space for developers to play with new things on the company's dime. Some good options:
- conferences
- hackfests
- spikes
After some investigation, you can layer in new tech where it makes sense, which makes for an even more compelling story on the resume.
Of course, you also have to have business buy-in that this is a worthwhile use of time. R&D and investing have a lot longer history than the craft of software engineering, so that's the approach I'd take.
I hope part of the goal of this article is to fight back against these trends. If the decision makers can gain more confidence in choosing boring/mature tech rather than trendy tech, there will be more demand for it. Many times people choose the trendy tech, not because it is the right tool, but because of the reasons you mention.
I fully agree with this, but the problem with this idea is that if we only ever choose to adopt the most boring mature technology, it doesn't give any room for better to ever exist. Be selective and judicious, but also open-minded and willing to re-evaluate. Sometimes the exciting things are exciting for very valid reasons. I'm okay with hype cycles, even if they are annoying to me as someone who constantly has to justify why I'm not adopting them, as long as they lead to maturation of innovative ideas.
> Sometimes the exciting things are exciting for very valid reasons
Very true! I would also add: Sometimes boring things are boring for reasons that actually make them poor solutions.
For example, some systems require tedious, mind-numbing configuration. This is boring, but also a good reason to NOT use something. If it takes hours and hours of manual tuning, by someone with special training, then the solution is incomplete and at least needs some better defaults and/or documentation. It might be a poor option.
Another example is a system that does not lend itself to automation. Requiring manual interaction is certainly boring, but also does not scale well. It is a valid reason to disqualify a solution.
Boring can often be a smell--an intuition that a solution is not fully solving the problem.
Most of my career was building dev tools, test infrastructure etc. The cardinal rule there was that it has to be boring.. Practically, this meant no surprises, almost invisible, people take it for granted and it just facilitates things without getting in your way.
Similar to electricity, air, water etc. Very few people really notice these things and talk about them. Till they stop working in which case, it's all people can think and speak of.
What is old becomes new, and what is new becomes old. You think you're creating some cool new "shitz", but someone else has already done it. You're just reinventing the wheel with some extra "shitz" tacked on
> Using tech that has been subjected to all those people hours of use means you’re less likely to run into edge cases, unexpected behaviour, or attributes and features that lack documentation or community knowledge.
Often this is part of the value proposition with commercial offerings - Obtaining access to solutions that work for people with much bigger problems than you.
This can differ subtly from the raw scale of deployment. For example, SQL Server and Oracle may not be as widely deployed as something like SQLite, but in the cases where they are deployed the demands tend to be much more severe.
[+] [-] _fat_santa|1 year ago|reply
[+] [-] aard|1 year ago|reply
By calling it boring, they characterize their _preference_ as the majority accepted, mature, obvious decision and anything else is merely software engineers chasing shiny objects. The truth is almost always more nuanced. Both solutions have pros and cons. They trade-off different values that resonate more or less with different people.
So, please be careful with the "it's boring and therefore obviously better" argument. Don't let it be a way to summarily dismiss someone else's preferences in favor of your own--without a deeper discussion of trade-offs. Otherwise it's no better than any other condescending attempt (ex. I'm in charge, so we are doing it this way. No one ever got fired choosing IBM/Microsoft/..) to win an argument without having to present real arguments.
[+] [-] whstl|1 year ago|reply
Anything that makes money is boring, anything that they like is boring, another poster saying that "boring tech stacks tend to be highly scalable".
By tomorrow we'll have people saying boring tech also brings world peace and cures world hunger.
The "boring" meme is just a conversation killer.
[+] [-] citrin_ru|1 year ago|reply
The same way I would say be wary an argument which can be boiled down to "it's newer so it's obviously better". I used to made such argument myself in the beginning of my career but now I see that proffering everything new is a bad strategy.
Comparing software objectively is hard (if not impossible), and there is a place for personal presences too. But if after a discussion of pros and cons it's not obvious which of two options is significantly better I would be inclined to choose an older and more established technology.
[+] [-] kubb|1 year ago|reply
[+] [-] mybazongas|1 year ago|reply
[+] [-] paulddraper|1 year ago|reply
But I would suggest that Kotlin gets you all the "boring advantages" of Java, with feature adds.
[+] [-] taeric|1 year ago|reply
I think you typically see this with older, established, things. But there is nothing guaranteeing it. And, indeed, it is often the result of specific action on the stewards of a technology.
This can often be couched in terms of backwards compatibility. Which is a clear action one can pursue to get stability. However, it can also be seen in greatly limiting scope. As an example, we love talking about scale, but that doesn't mean you have to design and build for scale you will never see.
[+] [-] vrnvu|1 year ago|reply
A system that breaks when updating dependencies, introduces unexpected behaviour through obscure defaults, forces you to navigate layers of abstraction isn't mature... (looking at you Spring and Java ecosystem), it's old and unstable.
Stability, predictability, and well-designed simplicity define maturity, not age alone.
Is Python mature and boring? With toolchain issues and headaches of all kinds... Newer languages like Go or Rust i.e solve all these toolchain issues and make it truly boring in the best way possible.
[+] [-] jasonthorsness|1 year ago|reply
[+] [-] Sponge5|1 year ago|reply
[+] [-] tmsbrg|1 year ago|reply
Think of how much time is wasted because so much software that's been written but not maintained and can't be used because of how libraries have "evolved" since then.
[+] [-] chefandy|1 year ago|reply
In my experience there are almost always some issues (either legit or misguided support requests,) PRs for docs and features, updates to libraries for vulnerabilities or deprecated code. Worth looking at stuff that isn’t open also. Even if it’s a 10 year old project and the last commit is from 6 months ago fixing a seemingly minor bug, if there more than a few stars or forks, and there aren’t ignored issues and PRs sitting there, I’d consider it trustworthy.
And if it does look abandoned but was active at some point, it’s always a good idea to take a stroll through the forks.
[+] [-] dspillett|1 year ago|reply
[+] [-] ysofunny|1 year ago|reply
but if you find a mature/dead project there's a chance it's just old and stable.
what I'm getting at is in an unmantained project any stranger should be able to figure out how to adrees any novel issues. it's the point of open source; I don't undrestand why this is failing. maybe beacuse understanding an anonymous code base is hard work?
[+] [-] LegionMammal978|1 year ago|reply
It's sometimes possible for a project to have 0 bugs to fix and 0 in-scope improvements (for performance, compatibility, etc.) left to make, but only if its scope is extremely limited. Even Knuth still gets bug reports for his age-old TeX.
[+] [-] blueflow|1 year ago|reply
If you get many "wtf" moments while doing this, the project is not mature.
[+] [-] 0xbadcafebee|1 year ago|reply
I have a feeling that I don't get many replies to job applications because the vast majority of work I've done is "boring", and the majority of open source code I've written is shell scripts. It all works fantastic, and has zero bugs and maintenance cost, but it's not sexy. Intellectual elitism has also defined my role ("DevOps Engineer" is literally just a "Sysadmin in the cloud", but we can't say that because we're supposed to be embarrassed to administrate systems); I'm fairly confident if my resume was more "Go and Rust" than "Python and Shell", I'd get hired in a heartbeat.
[+] [-] rqtwteye|1 year ago|reply
[+] [-] pjmlp|1 year ago|reply
[+] [-] blenderob|1 year ago|reply
What are some boring techs you use that you cannot live without? How long have you been using them?
For me, it'd be stuff like Vim, C, Python, Fedora, mutt and I've been using them for 25-30 years! How about you?
[+] [-] pjmlp|1 year ago|reply
Just as an idea, not listing everything.
[+] [-] SatvikBeri|1 year ago|reply
[+] [-] cguess|1 year ago|reply
[+] [-] tmsbrg|1 year ago|reply
"Cannot live without" is a strong wording, but software that I use a lot and that's mature/stable in my experience: shell (zsh, bash, sh), GNU utils, vim, nmap, xfce, git, ssh, mpv, Xorg, curl, and lots of little old CLI tools.
[+] [-] corinroyal|1 year ago|reply
[+] [-] rollcat|1 year ago|reply
Debian. Moves at its own pace, flexible yet stable enough to cope with my idea of a smart move.
Go. I've been playing with it since before 1.0, threw it into production at my first occasion, and all those years it continues to deliver.
Django. Identical story.
...StarCraft (1, then 2). Technically not "tech", but in a competitive setting, it remains strategically, tactically, and mechanically demanding, it reflects that path of mastery, "teach yourself programming in ten years". It shaped my spirit, attitude, but also humility.
[+] [-] uallo|1 year ago|reply
[+] [-] qaq|1 year ago|reply
[+] [-] _fat_santa|1 year ago|reply
Express has so many different uses and I've used it on very large scale backend projects for Fortune 500's, shoved it inside lambda functions, and used it to host email templates and build dev tooling with it to overcome shitty API's at work that always go down.
In all those times I don't think I've ever run into an issue that wasn't already solved
[+] [-] grandempire|1 year ago|reply
https://danluu.com/boring-languages/
[+] [-] esafak|1 year ago|reply
[+] [-] gregors|1 year ago|reply
Maybe it makes sense for your business maybe it doesn't. If you don't want to be on the forefront of technology, well don't. I don't think that launching every startup using the late adopter strategy is necessarily going to result in better business performance. Those that find a better way to do things will win.
[+] [-] whatever1|1 year ago|reply
[+] [-] tithe|1 year ago|reply
[+] [-] sunsetSamurai|1 year ago|reply
And also these legacy techs don't pay that much in general, for every consultant making bank fixing COBOL bugs there are probably dozens or more COBOL developer making less than a javascript developer, so you'll find yourself making less money than a kid with a 3 years of experience in web development, and when you go out in the market trying to switch jobs, you'll have a hard time finding a new job or salaries will suck. Don't be stupid and become the fall guy to keep the legacy debt going while everybody else in the company is learning the in-demand cool stuff and padding their resumes with hire able skills. You will regret it.
[+] [-] mooreds|1 year ago|reply
But introducing it willy nilly into production applications because you want to gain experience with it is bad. Bad for the business, at least. For you it might be resume driven development.
That's why I always advocate for time and space for developers to play with new things on the company's dime. Some good options:
- conferences
- hackfests
- spikes
After some investigation, you can layer in new tech where it makes sense, which makes for an even more compelling story on the resume.
Of course, you also have to have business buy-in that this is a worthwhile use of time. R&D and investing have a lot longer history than the craft of software engineering, so that's the approach I'd take.
[+] [-] francisofascii|1 year ago|reply
[+] [-] mybazongas|1 year ago|reply
[+] [-] phlakaton|1 year ago|reply
[+] [-] mixmastamyk|1 year ago|reply
[+] [-] darksaints|1 year ago|reply
[+] [-] aard|1 year ago|reply
Very true! I would also add: Sometimes boring things are boring for reasons that actually make them poor solutions.
For example, some systems require tedious, mind-numbing configuration. This is boring, but also a good reason to NOT use something. If it takes hours and hours of manual tuning, by someone with special training, then the solution is incomplete and at least needs some better defaults and/or documentation. It might be a poor option.
Another example is a system that does not lend itself to automation. Requiring manual interaction is certainly boring, but also does not scale well. It is a valid reason to disqualify a solution.
Boring can often be a smell--an intuition that a solution is not fully solving the problem.
[+] [-] mybazongas|1 year ago|reply
[+] [-] xnx|1 year ago|reply
[+] [-] noufalibrahim|1 year ago|reply
Most of my career was building dev tools, test infrastructure etc. The cardinal rule there was that it has to be boring.. Practically, this meant no surprises, almost invisible, people take it for granted and it just facilitates things without getting in your way.
Similar to electricity, air, water etc. Very few people really notice these things and talk about them. Till they stop working in which case, it's all people can think and speak of.
[+] [-] nuc1e0n|1 year ago|reply
[+] [-] frontalier|1 year ago|reply
let's schedule deployment for friday afternoon
[+] [-] MangoCoffee|1 year ago|reply
What is old becomes new, and what is new becomes old. You think you're creating some cool new "shitz", but someone else has already done it. You're just reinventing the wheel with some extra "shitz" tacked on
[+] [-] bob1029|1 year ago|reply
Often this is part of the value proposition with commercial offerings - Obtaining access to solutions that work for people with much bigger problems than you.
This can differ subtly from the raw scale of deployment. For example, SQL Server and Oracle may not be as widely deployed as something like SQLite, but in the cases where they are deployed the demands tend to be much more severe.