11 ms·

Boring Technology Checklist

173 points by macdonst 5y ago

mrkentutbabi 5y ago
What about between 2 boring technologies? For example I’m debating between Eleventy and Hugo (because I know both JS and Go, but not Ruby so I will skip Jekyll)
- dsr_ 5y ago
  Compare them in your particular scenario. Only you know what is important to you. If choosing for a company, ask the people who will have to work with it. Maybe one has more responsive developers, or a more helpful community.
- Cthulhu_ 5y ago
  The fact you worry about what language they're written in - while you shouldn't need to ever edit any of their code - already implies they're not boring and you're overthinking the decision already. Pick the one that gets you up and running the fastest, ideally one that doesn't rely on you installing additional runtimes.
  - 9dev 5y ago
    In principle you’re absolutely right, but Hugo actually comes with lots of strings attached due to their choice of Go, like having to use Go templates for example - which can be weird if you don’t have a Go background. The more elaborate constructs you’re trying to build, the more you need to research how the Hugo Go runtime works to sort out quirks.
- erikpukinskis 5y ago
  Flip a coin, try the first one out, and if anything pops up in a few days that makes you think the other might be more suitable, evaluate the other one. I recently started experimenting with Snowpack for JS build. I realized it doesn’t do sourcemaps very will so I grabbed Parcel. That worked great but doesn’t have a testing story and Vite has a couple options there. Vite has been good. It was work to evaluate each of those and switch between them. But not that much work really since I hadn’t committed a huge codebase yet. But it was worth it because now I know why you might choose one over the other. Granted the “boring” choice would be Webpack.
  - ithrow 5y ago
    This a good advice for dealing with 'decision paralysis' which can make you waste more time than just trying out the options.
  - foobiekr 5y ago
    I do this. But 1d20 / options. Crit fail means ignore for a week otherwise divide up the space evenly and extra slots mean re-roll. Having the option to punt is useful.
  - mrkentutbabi 5y ago
    Good advice thanks
- chrisweekly 5y ago
  Before you spend much time on a pure (thus limited) SSG, I recommend taking a close look at https://Remix.run https://Remix.run. Remix supports a superset of Eleventy or Hugo (or Jekyll or even NextJS export). It's too new to be considered "boring", but it leverages OG web standards and defaults to web platform-native foundations. Given its provenance and the authors' bona fides, I'm betting heavy it sticks around for the long haul. I'm unaffiliated w the project, but I've been doing web-related things for a living since 1998, and for me Remix is a breath of fresh air and the successor to NextJS as my framework of choice.
  - Zababa 5y ago
    > Given its provenance and the authors' bona fides, I'm betting heavy it sticks around for the long haul. That's what people said for Redwood.js. One year later and it's mostly forgotten.
    - chrisweekly 5y ago
      So? "People" may have said all kinds of things about Redwood or the price of rice in China. I never promoted Redwood, and (to engage with your off-base "rejoinder") objectively speaking, it didn't offer any advantages over NextJS. Remix, on the other hand, is fundamentally different from any other framework.
- egypturnash 5y ago
  The truly boring choice for your blog is PHP and/or Perl. Wordpress, Movable Type, or possibly Textpattern if you are feeling a little edgy.
- mrweasel 5y ago
  Boring is on a scale, and you need a reference to assess the level of boringness. Eleventy, Hugo and Jekyll are all a little to non-boring compared to ssg6 or just throwing txt files in www-root.
mwcampbell 5y ago
I was surprised to find this published on begin.com, which offers an app deployment platform based on AWS Lambda. So are Lambda, API Gateway, and friends considered boring now?
- zdw 5y ago
  They may not be, but cgi-bin, webservers, and monitoring via grep /var/log/www/*.log are.
  - Cthulhu_ 5y ago
    You say that, but setting up a LAMP stack from scratch is more involved than just yeeting something onto GCP these days.
    - mschuster91 5y ago
      On Debian, a LAMP stack should not take more than an hour to set up from scratch.
- tikhonj 5y ago
  Nobody gets fired for choosing IBM, and nobody gets fired for choosing AWS. The corollary that's missing, of course, is that they often should get fired—but popular (sorry, "boring") choices have a momentum of their own.
- erikpukinskis 5y ago
  Is lambda really that different from any other server technology? It’s just a container that you have to boot and it handles web requests, right? They boot fast, so for a low traffic site you can worry less about cold start, is there any other difference with any other containerized web server?
  - travisjungroth 5y ago
    Yes. In theory it would be the same but practically there are lots of gotchas. For a simple example, having a calculated cache on startup that five seconds would be fine on a traditional server but not on lambda.
lmeyerov 5y ago
Missing two of the biggest: - hireability: large community of developers to hire from today + years from now - low risk of abandonment: long history of development, stable funding, and ideally many users+contributors from diff orgs using in commercial contexts Not easy for startups and new frameworks to achieve 'boring' status!
- kitd 5y ago
  The metric I use is "StackOverflowability". It's 2am and I am desperate to fix a customers problem. What's the chance of me finding the answer on SO? Good documentation is obviously helpful, but SO expresses knowledge in a Q&A format much better.
- miiiiiike 5y ago
  This is where Angular dies. Great framework. There's almost no amount of money that you can pay someone to learn Angular in 2022.
  - hughrr 5y ago
    What is everyone gyrating around at the moment? I haven’t touched front end for about a decade. It was jquery back then.
    - lenzm 5y ago
      I'd say React has reached boring by JS standards.
      - macdonst 5y ago
        Except for React introduces major changes with every new version causing thrash.
        robbs 5y ago
        React hasn’t really changed since hooks and that’s been several years.
TacticalCoder 5y ago
Weirdly enough I do believe Clojure ticks the boxes from that checklist. It's familiar in that it both "supports popular language runtimes" (runs on top of the JVM or transpiles to JavaScript) and it's a Lisp dialect (or close enough) and Lisps have been around since a very long time. It's incredibly stable: so stable some libraries commonly used haven't been updated in years. There's also very little code churn inside Clojure's own codebase. It is very reliable. It's limits and trade offs are well known. Somehow I though my language of choice was "edgy" but I realize it may actually be "boring": a dialect from a very old family of language running on top of a boring tech (the JVM).
- Cthulhu_ 5y ago
  How about hiring though? If you have a vacancy for a Clojure developer, how many applicants could you expect? When it comes to programming languages, I'd stick to the top 10 languages if your company isn't hip enough to attract a certain kind of developer on its own.
  - ithrow 5y ago
    Hiring wasn't in the articles' checklist though ;) Valid point anyway
  - exdsq 5y ago
    On the other hand you attract a certain kind of developer with those roles than generic languages.
    - Steltek 5y ago
      If you're using your tech stack as a hiring filter, it doesn't count as "Boring Technology".
      - exdsq 5y ago
        No I appreciate that - my point is you can get better engineers that you might deserve at your startup by using a language like Clojure to entice them. I know people who work for a good discount if it’s on a tech stack they enjoy and is fairly rare to find.
jalanco 5y ago
One day, if we wait long enough, The Boring Company technology will be boring technology.
ChrisArchitect 5y ago
Hey OP or mods, could you please update this link Dunno where the staging server came from https://blog.begin.com/posts/2022-01-27-the-boring-technology-checklist https://blog.begin.com/posts/2022-01-27-the-boring-technolog...
- macdonst 5y ago
  Whelp, I'm an idiot for copying the wrong url. I don't seem to be able to edit the url, only the title.
- dang 5y ago
  Ok, changed from https://blog.staging.begin.com/posts/2022-01-27-the-boring-technology-checklist https://blog.staging.begin.com/posts/2022-01-27-the-boring-t.... Thanks!
- andrewf 5y ago
  I'm years out of date on this stuff, but I note the staging URL has found its way into Google as well, you might be able to fix that up by adjusting the <link rel="canonical" href="https://blog.staging.begin.com/ https://blog.staging.begin.com/..." /> to point to the authoritative URL even when the page is on the staging server.
Steltek 5y ago
This article would be enhanced with concrete examples. The "Boring Technology" argument is hard to attack because it's an opinion, an ideal. It's a good ideal, mind you, but it has the problem of being different for each person, even if they're all on the same team looking at the same use case. Another good extension to the topic would also be defining when Boring Technology becomes Ancient Technology. You need to hit that middle of the tech curve where it's understood and stable but also still being maintained and keeping up with modern needs.
- deltarholamda 5y ago
  I think the flexibility of the ideal is part of what makes it so attractive. "Boring" may mean some pretty cutting-edge technology because your team is so thoroughly steeped in it that they know it back to front. For me, "boring" means avoiding things like Kubernetes because it's an ecosystem with which I am woefully unfamiliar and I can more or less achieve with other (possibly less efficient) means. Ted Dziuba made a point a while back that the three tools for systems engineering are money, time, and code, and they should be used in that order. It's a sort of shorthand for "boring" to just buy a bigger server, or spend the time to leverage existing and know Unix tools, and then if all that fails, use some gimcrack new tech to solve your problems. (Though, I'd say that the biggest impediment to leveraging "boring" technologies is correctly determining what your problem is. Sometimes we focus on the wrong metrics, or the right metrics at the wrong time, and that skews our decision making.)
- deleted 5y ago
  [deleted]
deleted 5y ago
[deleted]
allochthon 5y ago
The discussion around "boring" technology is an important one. Where to draw the line will be pretty context-dependent. An aerospace firm will put the line here, and a tech startup focusing on a low-risk use case will draw the line somewhere else. And the developers and other stakeholders will be relevant as well. In this context, the checklist at the bottom is interesting food for thought. But I would be wary of relying on it for choices around what technology to adopt, because such decisions will always need to be considered in context. In that sense, the checklist feels well-meaning and even insightful, but a little too concrete.
- julosflb 5y ago
  In aerospace engineering you would usually select technologies based on a concept of technology readiness level, which provides a framework for evaluating new technology and make sure you are in control of their maturity. https://en.wikipedia.org/wiki/Technology_readiness_level https://en.wikipedia.org/wiki/Technology_readiness_level
aeternum 5y ago
If the ability to keep the site up is any indication, it looks like boring tech does not work as well in practice as the theory would have you believe.
wrnr 5y ago
I don't consider it my job to do the same thing in the same way to accomplish the same thing.
ape4 5y ago
I hate to say it, but in many ways Windows checks many boxes - its backwards compatible for decades. Programs from 30 years ago still work fine.
- mixmastamyk 5y ago
  The core is fine, it’s being at the whim of MS’s hostile marketing and sales departments that are decidedly not boring.
  - ape4 5y ago
    The ads in the start menu were a low but it's very cool how everything keeps working And I love Linux.
- mrweasel 5y ago
  Hate to agree, but yes. A C++ application using the APIs provided by Windows is pretty much unbreakable by time.
sedatk 5y ago
> biases for non-breaking changes easing long term maintainability So, not ElasticSearch.
- mrweasel 5y ago
  Or Kubernetes
friedman23 5y ago
A lot of this boring technology talk just seems like an excuse not to learn something new. "X works fine why are we using Y?" "See Y doesn't cover every X use case perfectly, we should have stuck with X!" The arguments are predictable at this point. We'd still be using Jquery for developing frontends if this mindset was pervasive.
Ishmaeli 5y ago
I feel like I've spent the last 10 years seeing "boring" in headlines and thinking mundane, when actually it was referring to tunneling. Now I'm finally conditioned to think tunneling first, and this. It's like BLM, whether I think Black Lives Matter or Bureau of Land Management, the reference is bound to be about the other one, sure as the the USB is always backwards.
fouadf 5y ago
Node.js seems boring at this point
- mrweasel 5y ago
  Yet NPM is a little to exciting.
- midrus 5y ago
  Not the 350+ libraries you need to pick to build anything useful with it.
hughrr 5y ago
Please also add ”doesn’t auto close three million ignored GitHub tickets” every week, the true quality metric these days.
- antod 5y ago
  Well, they were boring tickets in the CADT sense. Seriously though, probably the difference being a boring project and being a bored project.
wyager 5y ago
> friendly community (Code of Conduct, blogs, chats, podcasts, etc.) In my experience, most of these things negatively correlate with stuff I actually want (like software quality or stability). It indicates a software ecosystem that exists mostly as an ersatz social outlet for a certain kind of person. The best softwares I use tend to have none of this stuff - maybe just a mailing list and a bug tracker.
- Jensson 5y ago
  Yeah, boring technology requires boring owners to ensure that stuff like Python 3 wont happen.
  - paulryanrogers 5y ago
    So one (albeit large) backward compatibility break every few decades is too much? I wonder how you'd classify JavaScript since the language is very backward compatible, yet the popular libraries built upon it break compatibility often.
- abernard1 5y ago
  Amen. An abundance of these things signal (to me) developers concerned with themselves, not the technology. People in this scene are going to be the first to switch languages/frameworks or introduce drama into what should otherwise be pedestrian problem solving exercises. And on a more concrete note, when it's 3AM and your pagerduty is lit up like a Christmas tree, are blogs, chats, podcasts what you're interested in? No way! You want cold hard documentation and crusty "tell-it-like-it-is" engineers or consultants. They're seldom bubbly, but they command respect and get it done.
goodpoint 5y ago
Familiarity supports popular language runtimes, tools, and idiomatic APIs experience deploying this technology to production today Stability follows a predictable release and versioning scheme (note: NOT frequent is fine and in some ways more desirable. security patches are always welcome of course.) biases for non-breaking changes easing long term maintainability publishes a regular changelog open-source and/or open-source backed service ideally public governance: roadmap, issue tracking, and decision making all visible Reliability can be trusted to work as expected; ideally does one thing well social proofs exist (careful!) Well understood limits, and trade-offs accessible docs objective benchmarks and/or published service quotas friendly community (Code of Conduct, blogs, chats, podcasts, etc.)
k__ 5y ago
I wonder, how many engineers will switch their jobs because they have to work with boring tech? Sure, the stack you're using isn't everything and other parts of a project can be just as exciting. But I often heard engineers complain about their company being stuck in the past and they wish to use all the cool tech they see in the news.
- bob1029 5y ago
  > But I often heard engineers complain about their company being stuck in the past and they wish to use all the cool tech they see in the news. This is becoming my go-to filter for determining if I would want to hire someone in the first place. Hypothetically, if someone told me they left their prior job because they wanted to "use cool tech" on an interview, I would be providing a strong "No" input to the process. The honest reality is that a lot of people are doing a job they probably should not be doing. If you want to be really good at writing software for other people, you should enjoy delivering experiences to your actual users. I find many developers can't even enumerate who their end users are these days.
  - k__ 5y ago
    Sure, that's the best case scenario. In my experience companies, especially the small ones, struggle to hire engineers. So, they try to spice their positions up with some hot new tech.
- kingcharles 5y ago
  I've worked at companies where many of the devs were not remotely excited about any new technologies and just wanted to do their 9-5 and get home to the wife and kids, which is a totally valid career choice. These guys just wanted to stick with what worked and what they knew. They LOVED boring.
heipei 5y ago
Personally I believe that even more important than picking boring technology is limiting the number of different technologies in your tech stack. That will allow you to collect more best practices, build better tooling and monitoring and develop operational experience in those few technologies than if it was spread across multiple similar stacks. Example: React is great for starting with smaller and/or progressively enhanced websites, but if you were to develop a large monolithic SPA you might benefit more from something like Ember. However it would be better to use one stack which can cover both use-cases, so you should probably go with React for both, otherwise you'll forever be rewriting the same code for both stacks and figuring out build and tooling issues twice. Another example: You might need a lightweight message queue for smaller background processing needs, and you might also need a proper distributed log. The former could be solved by any number of queues, while the latter calls for something like Kafka. If Kafka can also reasonably cover the first use-case you should try to use it for both.
- deleted 5y ago
  [deleted]
- perrygeo 5y ago
  Exactly. Choose boring technology, but more importantly choose technology that works within your org and keep it consistent. Say your company chooses risky, bleeding edge tech and uses it everywhere. You'll build institutional knowledge that can be transferred across projects, lowering the risk. If every single app or microservice uses a different "boring technology" - one team is using Python and Postgres, another team is using Ruby and MySQL, etc - the knowledge gets siloed quickly which increases risk, no matter how "boring" those individual choices may seem.
62951413 5y ago
A boring technology is one with which a large number of developers have previous production experience with. Or probably even "of the developers you can realistically expect to hire".
- ghughes 5y ago
  Better yet, hire developers who enjoy and excel at selecting and utilizing emerging technologies that will be a better long-term fit for the problem at hand. This is of course more difficult, but makes for a better team and product. I want my competitors to be afraid of technology and to de-prioritize hiring generalists.
dwohnitmok 5y ago
I think commentators are missing that a big part of boring technology is, well, that it's boring. If developers are excited to use that technology, instead of just thinking "meh just another one of those companies using X" then it's probably not boring. If your technology gets developers excited then it's not boring. As per the original article that introduced the term, that doesn't mean that it's a priori a bad thing, but it does mean that the bar for the other things it brings to the table needs to be higher and that most startups only get a limited number of technologies to be excited about.
xupybd 5y ago
I think F# meets all of the checklist items for me. I'm still not going to consider it boring as it's too esoteric.
lukemunn 5y ago
Interesting to see a few posts on HN recently advocating for 'dumb' or 'boring' tech as I'd been writing an article on 'dumb technology' along the same lines. Comments welcome. https://www.researchgate.net/publication/358248465_Dumb_Technology_Calm_and_Convivial_Tools_as_the_Future_of_Digitalization https://www.researchgate.net/publication/358248465_Dumb_Tech...
lostcolony 5y ago
This is fine insofar as it provides a checklist to evaluate if technology is boring, but it rests entirely on "Choose Boring Technologies", which I've never found particularly compelling. It's less "Choose Boring Technologies" and more "Don't introduce something new just because it's new". Have a compelling reason. And both this article, and the original Choose Boring Technologies, kinda miss that. I'd be much more interested in guidelines of when to choose something new; a prior job prior to my joining chose Erlang for a mid-sized project, despite no one on the team knowing it, and it was a success. So we chose it (after I joined) for a large project, and it was, to quote the executive of a business unit it was for "the biggest success to come out of (our department)". Both of these projects -could- have been done in one of the existing house languages...they would not have been done as quickly, resulted in nearly as good an outcome (predominantly amongst resiliency, which is why we chose Erlang), nor have given the team as much enjoyment (itself being part of the reason for the results, as a knock on effect).
tptacek 5y ago
This seems mostly like a rhetorical way to launder non-boring technology into boring shops. There's nothing on this checklist than an "exciting" new database couldn't have right out of the gate. Like, put something like "doesn't use Raft" in the checklist!
drewm1980 5y ago
"All technology will change and improve with time" Tech can and does frequently get worse. All you have to do is keep adding features indescriminately or let code with external dependencies rot.
- drewm1980 5y ago
  Which is to say that I have experienced boring tech in our stack get worse and cost an unexpected "innovation token".

173 points by macdonst 5y ago

What about between 2 boring technologies? For example I’m debating between Eleventy and Hugo (because I know both JS and Go, but not Ruby so I will skip Jekyll)

dsr_ 5y ago
Compare them in your particular scenario. Only you know what is important to you. If choosing for a company, ask the people who will have to work with it. Maybe one has more responsive developers, or a more helpful community.
Cthulhu_ 5y ago
The fact you worry about what language they're written in - while you shouldn't need to ever edit any of their code - already implies they're not boring and you're overthinking the decision already. Pick the one that gets you up and running the fastest, ideally one that doesn't rely on you installing additional runtimes.
- 9dev 5y ago
  In principle you’re absolutely right, but Hugo actually comes with lots of strings attached due to their choice of Go, like having to use Go templates for example - which can be weird if you don’t have a Go background. The more elaborate constructs you’re trying to build, the more you need to research how the Hugo Go runtime works to sort out quirks.
erikpukinskis 5y ago
Flip a coin, try the first one out, and if anything pops up in a few days that makes you think the other might be more suitable, evaluate the other one. I recently started experimenting with Snowpack for JS build. I realized it doesn’t do sourcemaps very will so I grabbed Parcel. That worked great but doesn’t have a testing story and Vite has a couple options there. Vite has been good. It was work to evaluate each of those and switch between them. But not that much work really since I hadn’t committed a huge codebase yet. But it was worth it because now I know why you might choose one over the other. Granted the “boring” choice would be Webpack.
- ithrow 5y ago
  This a good advice for dealing with 'decision paralysis' which can make you waste more time than just trying out the options.
- foobiekr 5y ago
  I do this. But 1d20 / options. Crit fail means ignore for a week otherwise divide up the space evenly and extra slots mean re-roll. Having the option to punt is useful.
- mrkentutbabi 5y ago
  Good advice thanks
chrisweekly 5y ago
Before you spend much time on a pure (thus limited) SSG, I recommend taking a close look at https://Remix.run https://Remix.run. Remix supports a superset of Eleventy or Hugo (or Jekyll or even NextJS export). It's too new to be considered "boring", but it leverages OG web standards and defaults to web platform-native foundations. Given its provenance and the authors' bona fides, I'm betting heavy it sticks around for the long haul. I'm unaffiliated w the project, but I've been doing web-related things for a living since 1998, and for me Remix is a breath of fresh air and the successor to NextJS as my framework of choice.
- Zababa 5y ago
  > Given its provenance and the authors' bona fides, I'm betting heavy it sticks around for the long haul. That's what people said for Redwood.js. One year later and it's mostly forgotten.
  - chrisweekly 5y ago
    So? "People" may have said all kinds of things about Redwood or the price of rice in China. I never promoted Redwood, and (to engage with your off-base "rejoinder") objectively speaking, it didn't offer any advantages over NextJS. Remix, on the other hand, is fundamentally different from any other framework.
egypturnash 5y ago
The truly boring choice for your blog is PHP and/or Perl. Wordpress, Movable Type, or possibly Textpattern if you are feeling a little edgy.
mrweasel 5y ago
Boring is on a scale, and you need a reference to assess the level of boringness. Eleventy, Hugo and Jekyll are all a little to non-boring compared to ssg6 or just throwing txt files in www-root.

mwcampbell 5y ago

I was surprised to find this published on begin.com, which offers an app deployment platform based on AWS Lambda. So are Lambda, API Gateway, and friends considered boring now?

zdw 5y ago
They may not be, but cgi-bin, webservers, and monitoring via grep /var/log/www/*.log are.
- Cthulhu_ 5y ago
  You say that, but setting up a LAMP stack from scratch is more involved than just yeeting something onto GCP these days.
  - mschuster91 5y ago
    On Debian, a LAMP stack should not take more than an hour to set up from scratch.
tikhonj 5y ago
Nobody gets fired for choosing IBM, and nobody gets fired for choosing AWS. The corollary that's missing, of course, is that they often should get fired—but popular (sorry, "boring") choices have a momentum of their own.
erikpukinskis 5y ago
Is lambda really that different from any other server technology? It’s just a container that you have to boot and it handles web requests, right? They boot fast, so for a low traffic site you can worry less about cold start, is there any other difference with any other containerized web server?
- travisjungroth 5y ago
  Yes. In theory it would be the same but practically there are lots of gotchas. For a simple example, having a calculated cache on startup that five seconds would be fine on a traditional server but not on lambda.

lmeyerov 5y ago

Missing two of the biggest: - hireability: large community of developers to hire from today + years from now - low risk of abandonment: long history of development, stable funding, and ideally many users+contributors from diff orgs using in commercial contexts Not easy for startups and new frameworks to achieve 'boring' status!

kitd 5y ago
The metric I use is "StackOverflowability". It's 2am and I am desperate to fix a customers problem. What's the chance of me finding the answer on SO? Good documentation is obviously helpful, but SO expresses knowledge in a Q&A format much better.
miiiiiike 5y ago
This is where Angular dies. Great framework. There's almost no amount of money that you can pay someone to learn Angular in 2022.
- hughrr 5y ago
  What is everyone gyrating around at the moment? I haven’t touched front end for about a decade. It was jquery back then.
  - lenzm 5y ago
    I'd say React has reached boring by JS standards.
    - macdonst 5y ago
      Except for React introduces major changes with every new version causing thrash.
      - robbs 5y ago
        React hasn’t really changed since hooks and that’s been several years.

TacticalCoder 5y ago

Weirdly enough I do believe Clojure ticks the boxes from that checklist. It's familiar in that it both "supports popular language runtimes" (runs on top of the JVM or transpiles to JavaScript) and it's a Lisp dialect (or close enough) and Lisps have been around since a very long time. It's incredibly stable: so stable some libraries commonly used haven't been updated in years. There's also very little code churn inside Clojure's own codebase. It is very reliable. It's limits and trade offs are well known. Somehow I though my language of choice was "edgy" but I realize it may actually be "boring": a dialect from a very old family of language running on top of a boring tech (the JVM).

Cthulhu_ 5y ago
How about hiring though? If you have a vacancy for a Clojure developer, how many applicants could you expect? When it comes to programming languages, I'd stick to the top 10 languages if your company isn't hip enough to attract a certain kind of developer on its own.
- ithrow 5y ago
  Hiring wasn't in the articles' checklist though ;) Valid point anyway
- exdsq 5y ago
  On the other hand you attract a certain kind of developer with those roles than generic languages.
  - Steltek 5y ago
    If you're using your tech stack as a hiring filter, it doesn't count as "Boring Technology".
    - exdsq 5y ago
      No I appreciate that - my point is you can get better engineers that you might deserve at your startup by using a language like Clojure to entice them. I know people who work for a good discount if it’s on a tech stack they enjoy and is fairly rare to find.

jalanco 5y ago

One day, if we wait long enough, The Boring Company technology will be boring technology.

ChrisArchitect 5y ago

Hey OP or mods, could you please update this link Dunno where the staging server came from https://blog.begin.com/posts/2022-01-27-the-boring-technology-checklist https://blog.begin.com/posts/2022-01-27-the-boring-technolog...

macdonst 5y ago
Whelp, I'm an idiot for copying the wrong url. I don't seem to be able to edit the url, only the title.
dang 5y ago
Ok, changed from https://blog.staging.begin.com/posts/2022-01-27-the-boring-technology-checklist https://blog.staging.begin.com/posts/2022-01-27-the-boring-t.... Thanks!
andrewf 5y ago
I'm years out of date on this stuff, but I note the staging URL has found its way into Google as well, you might be able to fix that up by adjusting the <link rel="canonical" href="https://blog.staging.begin.com/ https://blog.staging.begin.com/..." /> to point to the authoritative URL even when the page is on the staging server.

Steltek 5y ago

This article would be enhanced with concrete examples. The "Boring Technology" argument is hard to attack because it's an opinion, an ideal. It's a good ideal, mind you, but it has the problem of being different for each person, even if they're all on the same team looking at the same use case. Another good extension to the topic would also be defining when Boring Technology becomes Ancient Technology. You need to hit that middle of the tech curve where it's understood and stable but also still being maintained and keeping up with modern needs.

deltarholamda 5y ago
I think the flexibility of the ideal is part of what makes it so attractive. "Boring" may mean some pretty cutting-edge technology because your team is so thoroughly steeped in it that they know it back to front. For me, "boring" means avoiding things like Kubernetes because it's an ecosystem with which I am woefully unfamiliar and I can more or less achieve with other (possibly less efficient) means. Ted Dziuba made a point a while back that the three tools for systems engineering are money, time, and code, and they should be used in that order. It's a sort of shorthand for "boring" to just buy a bigger server, or spend the time to leverage existing and know Unix tools, and then if all that fails, use some gimcrack new tech to solve your problems. (Though, I'd say that the biggest impediment to leveraging "boring" technologies is correctly determining what your problem is. Sometimes we focus on the wrong metrics, or the right metrics at the wrong time, and that skews our decision making.)
deleted 5y ago
[deleted]

deleted 5y ago

[deleted]

allochthon 5y ago

The discussion around "boring" technology is an important one. Where to draw the line will be pretty context-dependent. An aerospace firm will put the line here, and a tech startup focusing on a low-risk use case will draw the line somewhere else. And the developers and other stakeholders will be relevant as well. In this context, the checklist at the bottom is interesting food for thought. But I would be wary of relying on it for choices around what technology to adopt, because such decisions will always need to be considered in context. In that sense, the checklist feels well-meaning and even insightful, but a little too concrete.

julosflb 5y ago
In aerospace engineering you would usually select technologies based on a concept of technology readiness level, which provides a framework for evaluating new technology and make sure you are in control of their maturity. https://en.wikipedia.org/wiki/Technology_readiness_level https://en.wikipedia.org/wiki/Technology_readiness_level

aeternum 5y ago

If the ability to keep the site up is any indication, it looks like boring tech does not work as well in practice as the theory would have you believe.

wrnr 5y ago

I don't consider it my job to do the same thing in the same way to accomplish the same thing.

ape4 5y ago

I hate to say it, but in many ways Windows checks many boxes - its backwards compatible for decades. Programs from 30 years ago still work fine.

mixmastamyk 5y ago
The core is fine, it’s being at the whim of MS’s hostile marketing and sales departments that are decidedly not boring.
- ape4 5y ago
  The ads in the start menu were a low but it's very cool how everything keeps working And I love Linux.
mrweasel 5y ago
Hate to agree, but yes. A C++ application using the APIs provided by Windows is pretty much unbreakable by time.

sedatk 5y ago

> biases for non-breaking changes easing long term maintainability So, not ElasticSearch.

mrweasel 5y ago
Or Kubernetes

friedman23 5y ago

A lot of this boring technology talk just seems like an excuse not to learn something new. "X works fine why are we using Y?" "See Y doesn't cover every X use case perfectly, we should have stuck with X!" The arguments are predictable at this point. We'd still be using Jquery for developing frontends if this mindset was pervasive.

Ishmaeli 5y ago

I feel like I've spent the last 10 years seeing "boring" in headlines and thinking mundane, when actually it was referring to tunneling. Now I'm finally conditioned to think tunneling first, and this. It's like BLM, whether I think Black Lives Matter or Bureau of Land Management, the reference is bound to be about the other one, sure as the the USB is always backwards.

fouadf 5y ago

Node.js seems boring at this point

mrweasel 5y ago
Yet NPM is a little to exciting.
midrus 5y ago
Not the 350+ libraries you need to pick to build anything useful with it.

hughrr 5y ago

Please also add ”doesn’t auto close three million ignored GitHub tickets” every week, the true quality metric these days.

antod 5y ago
Well, they were boring tickets in the CADT sense. Seriously though, probably the difference being a boring project and being a bored project.

wyager 5y ago

> friendly community (Code of Conduct, blogs, chats, podcasts, etc.) In my experience, most of these things negatively correlate with stuff I actually want (like software quality or stability). It indicates a software ecosystem that exists mostly as an ersatz social outlet for a certain kind of person. The best softwares I use tend to have none of this stuff - maybe just a mailing list and a bug tracker.

Jensson 5y ago
Yeah, boring technology requires boring owners to ensure that stuff like Python 3 wont happen.
- paulryanrogers 5y ago
  So one (albeit large) backward compatibility break every few decades is too much? I wonder how you'd classify JavaScript since the language is very backward compatible, yet the popular libraries built upon it break compatibility often.
abernard1 5y ago
Amen. An abundance of these things signal (to me) developers concerned with themselves, not the technology. People in this scene are going to be the first to switch languages/frameworks or introduce drama into what should otherwise be pedestrian problem solving exercises. And on a more concrete note, when it's 3AM and your pagerduty is lit up like a Christmas tree, are blogs, chats, podcasts what you're interested in? No way! You want cold hard documentation and crusty "tell-it-like-it-is" engineers or consultants. They're seldom bubbly, but they command respect and get it done.

goodpoint 5y ago

Familiarity supports popular language runtimes, tools, and idiomatic APIs experience deploying this technology to production today Stability follows a predictable release and versioning scheme (note: NOT frequent is fine and in some ways more desirable. security patches are always welcome of course.) biases for non-breaking changes easing long term maintainability publishes a regular changelog open-source and/or open-source backed service ideally public governance: roadmap, issue tracking, and decision making all visible Reliability can be trusted to work as expected; ideally does one thing well social proofs exist (careful!) Well understood limits, and trade-offs accessible docs objective benchmarks and/or published service quotas friendly community (Code of Conduct, blogs, chats, podcasts, etc.)

k__ 5y ago

I wonder, how many engineers will switch their jobs because they have to work with boring tech? Sure, the stack you're using isn't everything and other parts of a project can be just as exciting. But I often heard engineers complain about their company being stuck in the past and they wish to use all the cool tech they see in the news.

bob1029 5y ago
> But I often heard engineers complain about their company being stuck in the past and they wish to use all the cool tech they see in the news. This is becoming my go-to filter for determining if I would want to hire someone in the first place. Hypothetically, if someone told me they left their prior job because they wanted to "use cool tech" on an interview, I would be providing a strong "No" input to the process. The honest reality is that a lot of people are doing a job they probably should not be doing. If you want to be really good at writing software for other people, you should enjoy delivering experiences to your actual users. I find many developers can't even enumerate who their end users are these days.
- k__ 5y ago
  Sure, that's the best case scenario. In my experience companies, especially the small ones, struggle to hire engineers. So, they try to spice their positions up with some hot new tech.
kingcharles 5y ago
I've worked at companies where many of the devs were not remotely excited about any new technologies and just wanted to do their 9-5 and get home to the wife and kids, which is a totally valid career choice. These guys just wanted to stick with what worked and what they knew. They LOVED boring.

heipei 5y ago

Personally I believe that even more important than picking boring technology is limiting the number of different technologies in your tech stack. That will allow you to collect more best practices, build better tooling and monitoring and develop operational experience in those few technologies than if it was spread across multiple similar stacks. Example: React is great for starting with smaller and/or progressively enhanced websites, but if you were to develop a large monolithic SPA you might benefit more from something like Ember. However it would be better to use one stack which can cover both use-cases, so you should probably go with React for both, otherwise you'll forever be rewriting the same code for both stacks and figuring out build and tooling issues twice. Another example: You might need a lightweight message queue for smaller background processing needs, and you might also need a proper distributed log. The former could be solved by any number of queues, while the latter calls for something like Kafka. If Kafka can also reasonably cover the first use-case you should try to use it for both.

deleted 5y ago
[deleted]
perrygeo 5y ago
Exactly. Choose boring technology, but more importantly choose technology that works within your org and keep it consistent. Say your company chooses risky, bleeding edge tech and uses it everywhere. You'll build institutional knowledge that can be transferred across projects, lowering the risk. If every single app or microservice uses a different "boring technology" - one team is using Python and Postgres, another team is using Ruby and MySQL, etc - the knowledge gets siloed quickly which increases risk, no matter how "boring" those individual choices may seem.

62951413 5y ago

A boring technology is one with which a large number of developers have previous production experience with. Or probably even "of the developers you can realistically expect to hire".

ghughes 5y ago
Better yet, hire developers who enjoy and excel at selecting and utilizing emerging technologies that will be a better long-term fit for the problem at hand. This is of course more difficult, but makes for a better team and product. I want my competitors to be afraid of technology and to de-prioritize hiring generalists.

dwohnitmok 5y ago

I think commentators are missing that a big part of boring technology is, well, that it's boring. If developers are excited to use that technology, instead of just thinking "meh just another one of those companies using X" then it's probably not boring. If your technology gets developers excited then it's not boring. As per the original article that introduced the term, that doesn't mean that it's a priori a bad thing, but it does mean that the bar for the other things it brings to the table needs to be higher and that most startups only get a limited number of technologies to be excited about.

xupybd 5y ago

I think F# meets all of the checklist items for me. I'm still not going to consider it boring as it's too esoteric.

lukemunn 5y ago

Interesting to see a few posts on HN recently advocating for 'dumb' or 'boring' tech as I'd been writing an article on 'dumb technology' along the same lines. Comments welcome. https://www.researchgate.net/publication/358248465_Dumb_Technology_Calm_and_Convivial_Tools_as_the_Future_of_Digitalization https://www.researchgate.net/publication/358248465_Dumb_Tech...

lostcolony 5y ago

This is fine insofar as it provides a checklist to evaluate if technology is boring, but it rests entirely on "Choose Boring Technologies", which I've never found particularly compelling. It's less "Choose Boring Technologies" and more "Don't introduce something new just because it's new". Have a compelling reason. And both this article, and the original Choose Boring Technologies, kinda miss that. I'd be much more interested in guidelines of when to choose something new; a prior job prior to my joining chose Erlang for a mid-sized project, despite no one on the team knowing it, and it was a success. So we chose it (after I joined) for a large project, and it was, to quote the executive of a business unit it was for "the biggest success to come out of (our department)". Both of these projects -could- have been done in one of the existing house languages...they would not have been done as quickly, resulted in nearly as good an outcome (predominantly amongst resiliency, which is why we chose Erlang), nor have given the team as much enjoyment (itself being part of the reason for the results, as a knock on effect).

tptacek 5y ago

This seems mostly like a rhetorical way to launder non-boring technology into boring shops. There's nothing on this checklist than an "exciting" new database couldn't have right out of the gate. Like, put something like "doesn't use Raft" in the checklist!

drewm1980 5y ago

"All technology will change and improve with time" Tech can and does frequently get worse. All you have to do is keep adding features indescriminately or let code with external dependencies rot.

drewm1980 5y ago
Which is to say that I have experienced boring tech in our stack get worse and cost an unexpected "innovation token".