9 ms·

Choose Boring Technology (2015)

148 points by pocketarc 4y ago

loceng 4y ago
Anyone else outweighed the word "Boring" to associate to The Boring Company?
davidkuennen 4y ago
React is a boring technologie for me by now and it was a great choice for my latest project. Many very mature libraries and excellent support all around.
martythemaniak 4y ago
I'm generally a fan of this, but following this too closely will eventually kill your company. Every currently boring technology was once a new hotness and eventually companies that are willing to try new things, or startups based entirely on new things will eat your lunch because they're more efficient, faster, etc. Put another way, this is a very fragile strategy. It consistently protects you from small, limited downsides, while opening you up to the occasional collapse. An organization which is constantly experimenting with new things will pay a consistent cost for all the failed experiments, but they are opening up themselves to huge upsides if one of them works.
- sealeck 4y ago
  I don't think your strategies are so different – the proposal here is not to _not_ adopt new technologies, but rather to ensure that you consider and manage the risk in doing so (which is very sensible IMO). Further most companies don't make money directly from their technology choices – they make money from the services they provide to customers (which in the vast majority of cases are different things).
- youngtaff 4y ago
  > I'm generally a fan of this, but following this too closely will eventually kill your company. But isn't that where innovation tokens come in - evaluate the risks of the technologies you're using and know when you're taking a risk IMV too many projects decide to try the new hotness without this evaluation, I've witnessed re-writes in the latest JS framework cost a company millions in lost revenue, also seen product rewrites take years and not deliver something that was much better than before Yes some teams can build create products on top off 'non-boring' technologies but also witness how many every day sites are build on old boring technologies such as Rails
- KronisLV 4y ago
  > ... eventually companies that are willing to try new things, or startups based entirely on new things will eat your lunch because they're more efficient, faster, etc. I am yet to see a company that is running their apps in Tomcat, Java and MySQL fail badly, even without containers and microservices or service meshes and serverless, since those generally tend to all be orthogonal to getting things done for most of the projects at the scales that my country (Latvia) needs. I think your point could be applicable in two particular cases: - where hype cycles affect the corporate policies and suddenly it's mandated that Kubernetes and microservices are used, because someone either likened their org to another that's 10x larger and has more resources, or just wanted to pad their CV/make their work sound more important; suddenly companies that don't use said tech cannot successfully work on any development contracts with said org - alternatively, where the projects actually need certain new technologies or approaches (aforementioned architectures, tools, things like machine learning etc.) for either large or interesting systems I don't believe that most boring enterprise systems out there will conform that much to either of these, unless you're working for a large org with huge projects. Definitely not for orgs that have technology not be a primary means of getting done (or at least isn't prioritized as such) and for whom a simple CRUD would suffice. Or, you know, governmental projects that are acquired through mountains of documentation and specs, most of which will change anyways. Scale and the industry matter a lot here, there is no one universal truth - in highly competitive markets, you're probably right!
  - sanderjd 4y ago
    I have seen such companies fail as they struggle to hire and it becomes more difficult to adapt quickly to more spry competition. If they are in a market without spry competition then it works fine. For instance, for internal applications where there is a top-down forbiddance of experimentation with new things. But even for internal apps, if experimentation is not forbidden, a forward-looking team might start effectively using (and hiring for) newer technologies and eventually get all the budget.
    - devonkim 4y ago
      The other part of the problem is that in a limited hiring pool your competition's labor pool overlaps quite directly with yours and now you need to have compensation packages similar to theirs potentially. I've seen companies have what amounts to the same stack as a large F500 enterprise (Java, Spring, AWS, etc.) and have massive hiring problems, turnover, and especially velocity of features to keep ahead of the big companies. Essentially, if you cannot iterate faster than your competitors sufficiently from the same customer market and hiring pool, you are designed to fail or in best case be acquired by your competition. There is a balance to be achieved between boring technology, boring customer market, boring hiring pool, and so forth when it comes to any company. You need at least two such major advantages to even bother starting a company IMO.
debarshri 4y ago
Rather than choosing a boring tech, I believe engineers should choose tech with which they can operate with highest operational confidence.
- k__ 4y ago
  I think, the filter function should be something like operational-confidence * value-delivered. High risk, high reward, etc.
- jstummbillig 4y ago
  From what I have gathered the recommendation to choose boring tech usually has this idea factored in already and is more of a conclusion than an aspiration.
- bigdubs 4y ago
  What one engineer can operate confidently doesn't necessarily extend to the rest of the team, who will have to support that system if that engineer leaves or has to work on other projects. The lowest common denominator on a team is boring.
- thomascgalvin 4y ago
  This is an accurate summary of the article, down to where the author says he wish he'd said something other than "boring."
k__ 4y ago
I think, this underestimates that most devs hate boredom. The will leave your company rather quickly, if you can't give them interesting tasks once in a while.
- slaw3 4y ago
  If it’s boring enough, do you need devs?
- hrunt 4y ago
  I think the presentation covers this fairly well. Give devs interesting work by having them solve interesting problems. If the technology stack is the "interesting problem" then you are wasting this developer excitement on something less valuable than higher-level business problems. Go up the stack, get devs excited to work on those higher-level problems, and spend less of that expensive dev time on high-risk software that has questionable impact on those higher-level problems.
  - aliswe 4y ago
    Exactly, the stack and infrastructure should be fairly boring - and - above all unsurprising. The exciting stuff should be in the actual application.
gampleman 4y ago
You also have so many hiring tokens. Not every company can have market beating comp, or high likelihood of super profitable stock, or world class super nice offices. Having exciting tech can be an actually cheap way to attract top talent.
- 0des 4y ago
  I can see how we got here though. There's so little exciting tech out now, compared to so much money and so much talent available.
- rossdavidh 4y ago
  Absolutely true that, but it can also be a way to make your maintenance needs require exotic skills you didn't need before, such that your already-scarce hiring tokens are stretched even thinner once that new person builds their thing and moves on. Which doesn't mean your point isn't valid, just that there is a flip side to it that it should be balanced against, and it is possible to err in either direction.
- thomascgalvin 4y ago
  Only tangentially related to your comment, but I've seen a very clean pattern where "the tech I'm going to use on this project" maps very neatly to "the tech I want to have on my resume the next time I'm looking for a job." I think someone called it resume driven development.
- coffeefirst 4y ago
  Sure, but if that's the appeal, it tends to attract the kind of person who looks at an old Rails app, and decides rather than cleaning it up the thing to do is replace it with a sea of graphql-fronted microservices that's nearly impossible to work on. There's other extremely cheap ways to compete: be family-friendly, open to remote, have sane processes, etc.
  - gampleman 4y ago
    Codebases in old tech and new tech can both be bad. I don't think that's necessarily an argument against either. Part of getting good people is getting people who want to build maintainable and solid stuff. > There's other extremely cheap ways to compete: be family-friendly, open to remote, have sane processes, etc. Of course. Depending on how badly you're struggling to hire, you might need to do a bunch of these.
zero_shift 4y ago
This again... The problems with boring technology are twofold. One, it's about rejecting newer tech on a bet you don't need their features. And two, it's about choosing older tech because you assume it's good enough for the one year, two year, five year plan. And there are a few places that falls down. The first is when the new tech features are really strategically relevant to where your company is right now. If you need rapid deployment of new infra as you roll out installations for new customers, choosing manual CloudFormation config over Terraform could be a bad call. If you don't know your target platform at this point, writing native code over something cross-platform like React Native or Electron could be an expensive mistake. On the second, every time I've seen someone quote this essay at work, it has always been for a bet that has ended up problematic or at least mixed result. The first time I saw it was in a mildly heated debate about whether we should use React. I lost the argument and that org chose Knockout.js with JSPs instead. You can guess how expensive that "pragmatic" decision turned out. The second time was at a startup where the "boring technology" was - ironically - MongoDB. Everyone there had worked with Mongo and our only prior RDBMS experience had been with Oracle and PL/SQL. The result was a mess because noSQL stores only work when you have inflexible query patterns, which is the opposite of product iteration at a startup. So I am sceptical. If you know where your business should differentiate itself, and what pressures it will be under, choosing a technology should be - if not obvious, at least a process you can follow. Relying on proxies like "innovation tokens" feels to me like a mistake because it is, fundamentally, trying to replace strategic thinking with a points system.
- gfodor 4y ago
  > Relying on proxies like "innovation tokens" feels to me like a mistake because it is, fundamentally, trying to replace strategic thinking with a points system. No, it’s making it clear that there’s a scarcity you have to manage that is non-obvious: too many novel tech choices and you end up getting burned by the sum of all their risks leading to perpetual problems. If you have engineers literally allocating themselves a fixed number of tokens they don’t understand the talk.
  - zero_shift 4y ago
    So why use any novel technologies, then? Why don't we use tech from the 1990s? Is it just neophilia? Or is it that tech companies, by their nature, are about automating new things by applying, building, leveraging new technology? And that they are invested in because people want to make a bet on those productivity multipliers?
adamnemecek 4y ago
This is such an uninteresting take. It's in the same category as "all programming languages are the same". I wonder where this comes from. Are all operating systems the same? Are all file systems the same? Are all databases the same? New tech generally tries to solve some problem. Maybe your project doesn't need that solution. Maybe you have been waiting for something to come along to solve that problem.
- subtra3t 4y ago
  The problem, is that the problems these "new techs" try to solve are usually problems that are not generally faced, or try to bring a new approach to a more general problem with already accepted solutions.
  - adamnemecek 4y ago
    Which new tech with some adoption is not solving a problem?
5350-uiop-1130 4y ago
I think you need the bitterness and pessimism of 30 years experience to have good judgement. A lot of new tech is developed or managed by 20 somethings who just don't have that.
- jb3689 4y ago
  A lot of new tech is also spun out of large companies where the original ideas were piloted internally (see Kubernetes, Bazel, a number of distributed databases)
- cheradenine_uk 4y ago
  I was just thinking that I could likely make a reasonably accurate guess to commenters age based on their reactions to this article. But you trigger an interesting question. Frankly, part of my value to an organisation /is/ the accrued scar tissue from working with exciting technology; "choose boring technology" has us greybeards nodding along as at least half our job is about saying "no" to things - by being good at making the value judgements about when something shiny is worth it, and to be worried about those unknown-unknowns as you're gonna get the call when it breaks at 3AM on a weekend. But: We're clearly not learning from this. Maybe if we don't let people burn themselves they won't discover the stove is hot? Is this just the way of things, or a function of the fact that older engineers are steadily driven out into 'management', and the industry keeps re-inventing the wheel every 5 years?
nus07 4y ago
I don’t think you should either choose boring technology or adopt shiny new technology . It’s always in the middle and what your appetite for risk and business and financial situation is . For a business that can take risks by all means you should adopt new technologies because that’s what the future is . For ones with less risk appetite like large hospitals or banks you want boring technology until the shiny new tech has become more mature and resolved initial kinks at which point you should switch over otherwise risk being obsolete .
rossdavidh 4y ago
I began programming at a large institution that chose (for them) boring technology; they got good results, but eventually had to build almost everything themselves because the software world had moved on and left them behind. Later, I worked at a smaller company that let a young talent bring in a newer, more complex technology stack, made for solving problems at a scale they not only didn't have, but would never even aspire to reach. His reason was clearly that he wanted it on his resume; it took me a while to figure out that was his supervisor's reason for letting him do it. Both probably left soon after, leaving behind a higher maintenance load that would have helped them only if they reached a scale 1,000x bigger than there was any prospect of. These two cases (and several others like them) have convinced me that it is possible to screw this up in either of two directions. No doubt there is a good rule of thumb to determine how to get it right, but I haven't found it yet. The best I know of is, to be aware that it is very possible to get this wrong in either direction.
- a-priori 4y ago
  "Choose boring technologies" doesn't imply "... and then never change ever again even when it becomes obsolete and unsupported". That's where the first company went wrong. It means to choose technology components that are stable and boring (but still actively developed with a healthy community around them!). It also means to break this rule if and when that thing is important enough to your success that it makes sense to spend innovation points on it because it'll set you apart. But also recognizing that those instances are rare, and that's where good engineering judgment and leadership comes in.
  - atoav 4y ago
    "Choose boring technologies" is one of those phrases that makes sense when it makes sense, unless it doesn't. I find the negative expression of the same idea much more fitting: "Don't choose technology purely out of exitement". In that negative version the word purely does the heavy lifting: If all you have as a reason to choose a thing is excitement it might be a bad choice unless you can afford a failed attempt. In reality very often the "more exciting" choice will also come with their own additional pros/cons. It might be that your exciting Rust-Webservice has a smaller community backing its components, but maybe the APIs of the few components you really interact with is such a joy to use that it will save you weeks over the Java equivalent, while giving you magnitudes faster startup times and decent testability. In programming there are so many angles to consider, that simplistic answers are rarely do reality justice. There is however the danger of wearing rose tinted glasses when weighing the cons of the more exciting solution.
dgb23 4y ago
> innovation tokens Aside: Sorry to be blunt but this is such a dumb term that distracts from some of the important lessons in this talk. The author confuses "innovation" with "novelty", "niche", "general familiarity" and so on. Choosing existing solutions has nothing to do with innovation. The innovation already happened. You're just integrating with it. But what about expertise, leverage, problem fit, cost, licensing, performance, bloat, implied workarounds, maintainability, community, attracting the right people and trust? What about simplicity? I think the bottom line here is to choose mastery and depth over novelty and breadth. Being really good at using very few orthogonal tools is a good thing. Spending more time on the abstraction layers above and below you rather than switching between arbitrary choices too. But these things have _nothing_ to do with how novel, niche or "innovative" a given tech choice is. That's just plain old conservatism, which can be an advantage or a disadvantage depending on what kind of work you're doing.
cassandratt 4y ago
Choose the appropriate tools for the job. I hate these idiotic posts that examine a sliver of a domain and think they have the answers to all of programming. It’s just naïveté on display, and this site eats it up.
pharmakom 4y ago
I much prefer Choose Simple Technology, where “simple” is as it is understood as in Rich Hickeys Simple Made Easy.
js8 4y ago
My rule of thumb is this: For the domain you work in, you CAN use cutting-edge technology. For things outside the product domain, use standard (boring, time-tested) technology to hedge risk. For example, when writing a DB, you might make use of a novel data structure, but don't use, for instance, an experimental parsing library.
skrebbel 4y ago
I feel like this article didn't age so well. It was written at the end of a decade long hype cycle when a lot of old ideas got replaced by new ones. A bunch of these new ideas (eg mongodb) went out of vogue, but a whole bunch simply got better and established. At the same time, a lot of previously boring technology caught up, so we now got to the point where formerly non-boring technology got more stable and established, and boring technology got, eh, less boring. Eg Java severely un-sucked itself as a language. And if you still don't like it, you can use Kotlin and still get a fantastic ecosystem, tooling, etc etc skipping all the reasons to choose boring tech. Postgres got all kinds of fancy new features, including indexable jsonb which lets it compete with lots of NoSQL DBs. And so on, and so forth. On the non-boring side, Go, Elixir, Rust, Redis all became stable, dependable technology choices that really aren't at all as risky as they used to be in 2015. Is Java more boring than Elixir? Sure, but is the Elixir ecosystem so tiny that picking it is a major risk? Definitely not. The gap between what used to be boring and not narrowed a lot. Of course there's still new non-boring tech, but somehow it all feels a bit less paradigm changing to me. Eg React turned front-end dev upside down. Vue and Svelte just iterate on its ideas a bit. Sure there's still some good ideas here. Maybe think twice before building a web app in 100% Rust, wasm-compiled on the frontend to a webgl based custom UI. But I don't think that's the kind of way-out-there stuff the authors of this article had in mind.
- KronisLV 4y ago
  > The gap between what used to be boring and not narrowed a lot. Of course there's still new non-boring tech, but somehow it all feels a bit less paradigm changing to me. What about new tech that's boring by design? To me, that kind of feels why Go succeeded: it didn't attempt to solve all of the world's problems, merely become a relatively simple language that one can pick up and be productive in reasonably quickly, while also having a decent amount of batteries included. Over the years, there have been relatively few major changes (generics come to mind, but those don't really break much old code at all) and it's remained somewhat stable/boring throughout the years.
asiachick 4y ago
Let's get concrete! What is boring tech in the context of creating an SPA website? A LAMP stack (seems too old and boring give that most SPAs want some form of real time updating) React? Is that old and boring yet or new and unproven? React with what (since react is just a framework for DOM manipulation Rails? Does that meet today's requirements? At the time it wasn't written for SPAs, was written for MPAs.
- kaixi 4y ago
  PHP + jQuery/Vue/Alpine + SQLite
dang 4y ago
Related: Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=30389591 https://news.ycombinator.com/item?id=30389591 - Feb 2022 (13 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=26211721 https://news.ycombinator.com/item?id=26211721 - Feb 2021 (361 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=25322651 https://news.ycombinator.com/item?id=25322651 - Dec 2020 (204 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=23444594 https://news.ycombinator.com/item?id=23444594 - June 2020 (282 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246 - July 2019 (344 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215 - March 2015 (212 comments)
chaostheory 4y ago
This makes total sense from an organizational POV, but a lot of developers do resume or CV focused development whether or not people admit it.

148 points by pocketarc 4y ago

Anyone else outweighed the word "Boring" to associate to The Boring Company?

React is a boring technologie for me by now and it was a great choice for my latest project. Many very mature libraries and excellent support all around.

martythemaniak 4y ago

I'm generally a fan of this, but following this too closely will eventually kill your company. Every currently boring technology was once a new hotness and eventually companies that are willing to try new things, or startups based entirely on new things will eat your lunch because they're more efficient, faster, etc. Put another way, this is a very fragile strategy. It consistently protects you from small, limited downsides, while opening you up to the occasional collapse. An organization which is constantly experimenting with new things will pay a consistent cost for all the failed experiments, but they are opening up themselves to huge upsides if one of them works.

sealeck 4y ago
I don't think your strategies are so different – the proposal here is not to _not_ adopt new technologies, but rather to ensure that you consider and manage the risk in doing so (which is very sensible IMO). Further most companies don't make money directly from their technology choices – they make money from the services they provide to customers (which in the vast majority of cases are different things).
youngtaff 4y ago
> I'm generally a fan of this, but following this too closely will eventually kill your company. But isn't that where innovation tokens come in - evaluate the risks of the technologies you're using and know when you're taking a risk IMV too many projects decide to try the new hotness without this evaluation, I've witnessed re-writes in the latest JS framework cost a company millions in lost revenue, also seen product rewrites take years and not deliver something that was much better than before Yes some teams can build create products on top off 'non-boring' technologies but also witness how many every day sites are build on old boring technologies such as Rails
KronisLV 4y ago
> ... eventually companies that are willing to try new things, or startups based entirely on new things will eat your lunch because they're more efficient, faster, etc. I am yet to see a company that is running their apps in Tomcat, Java and MySQL fail badly, even without containers and microservices or service meshes and serverless, since those generally tend to all be orthogonal to getting things done for most of the projects at the scales that my country (Latvia) needs. I think your point could be applicable in two particular cases: - where hype cycles affect the corporate policies and suddenly it's mandated that Kubernetes and microservices are used, because someone either likened their org to another that's 10x larger and has more resources, or just wanted to pad their CV/make their work sound more important; suddenly companies that don't use said tech cannot successfully work on any development contracts with said org - alternatively, where the projects actually need certain new technologies or approaches (aforementioned architectures, tools, things like machine learning etc.) for either large or interesting systems I don't believe that most boring enterprise systems out there will conform that much to either of these, unless you're working for a large org with huge projects. Definitely not for orgs that have technology not be a primary means of getting done (or at least isn't prioritized as such) and for whom a simple CRUD would suffice. Or, you know, governmental projects that are acquired through mountains of documentation and specs, most of which will change anyways. Scale and the industry matter a lot here, there is no one universal truth - in highly competitive markets, you're probably right!
- sanderjd 4y ago
  I have seen such companies fail as they struggle to hire and it becomes more difficult to adapt quickly to more spry competition. If they are in a market without spry competition then it works fine. For instance, for internal applications where there is a top-down forbiddance of experimentation with new things. But even for internal apps, if experimentation is not forbidden, a forward-looking team might start effectively using (and hiring for) newer technologies and eventually get all the budget.
  - devonkim 4y ago
    The other part of the problem is that in a limited hiring pool your competition's labor pool overlaps quite directly with yours and now you need to have compensation packages similar to theirs potentially. I've seen companies have what amounts to the same stack as a large F500 enterprise (Java, Spring, AWS, etc.) and have massive hiring problems, turnover, and especially velocity of features to keep ahead of the big companies. Essentially, if you cannot iterate faster than your competitors sufficiently from the same customer market and hiring pool, you are designed to fail or in best case be acquired by your competition. There is a balance to be achieved between boring technology, boring customer market, boring hiring pool, and so forth when it comes to any company. You need at least two such major advantages to even bother starting a company IMO.

debarshri 4y ago

Rather than choosing a boring tech, I believe engineers should choose tech with which they can operate with highest operational confidence.

k__ 4y ago
I think, the filter function should be something like operational-confidence * value-delivered. High risk, high reward, etc.
jstummbillig 4y ago
From what I have gathered the recommendation to choose boring tech usually has this idea factored in already and is more of a conclusion than an aspiration.
bigdubs 4y ago
What one engineer can operate confidently doesn't necessarily extend to the rest of the team, who will have to support that system if that engineer leaves or has to work on other projects. The lowest common denominator on a team is boring.
thomascgalvin 4y ago
This is an accurate summary of the article, down to where the author says he wish he'd said something other than "boring."

k__ 4y ago

I think, this underestimates that most devs hate boredom. The will leave your company rather quickly, if you can't give them interesting tasks once in a while.

slaw3 4y ago
If it’s boring enough, do you need devs?
hrunt 4y ago
I think the presentation covers this fairly well. Give devs interesting work by having them solve interesting problems. If the technology stack is the "interesting problem" then you are wasting this developer excitement on something less valuable than higher-level business problems. Go up the stack, get devs excited to work on those higher-level problems, and spend less of that expensive dev time on high-risk software that has questionable impact on those higher-level problems.
- aliswe 4y ago
  Exactly, the stack and infrastructure should be fairly boring - and - above all unsurprising. The exciting stuff should be in the actual application.

gampleman 4y ago

You also have so many hiring tokens. Not every company can have market beating comp, or high likelihood of super profitable stock, or world class super nice offices. Having exciting tech can be an actually cheap way to attract top talent.

0des 4y ago
I can see how we got here though. There's so little exciting tech out now, compared to so much money and so much talent available.
rossdavidh 4y ago
Absolutely true that, but it can also be a way to make your maintenance needs require exotic skills you didn't need before, such that your already-scarce hiring tokens are stretched even thinner once that new person builds their thing and moves on. Which doesn't mean your point isn't valid, just that there is a flip side to it that it should be balanced against, and it is possible to err in either direction.
thomascgalvin 4y ago
Only tangentially related to your comment, but I've seen a very clean pattern where "the tech I'm going to use on this project" maps very neatly to "the tech I want to have on my resume the next time I'm looking for a job." I think someone called it resume driven development.
coffeefirst 4y ago
Sure, but if that's the appeal, it tends to attract the kind of person who looks at an old Rails app, and decides rather than cleaning it up the thing to do is replace it with a sea of graphql-fronted microservices that's nearly impossible to work on. There's other extremely cheap ways to compete: be family-friendly, open to remote, have sane processes, etc.
- gampleman 4y ago
  Codebases in old tech and new tech can both be bad. I don't think that's necessarily an argument against either. Part of getting good people is getting people who want to build maintainable and solid stuff. > There's other extremely cheap ways to compete: be family-friendly, open to remote, have sane processes, etc. Of course. Depending on how badly you're struggling to hire, you might need to do a bunch of these.

zero_shift 4y ago

This again... The problems with boring technology are twofold. One, it's about rejecting newer tech on a bet you don't need their features. And two, it's about choosing older tech because you assume it's good enough for the one year, two year, five year plan. And there are a few places that falls down. The first is when the new tech features are really strategically relevant to where your company is right now. If you need rapid deployment of new infra as you roll out installations for new customers, choosing manual CloudFormation config over Terraform could be a bad call. If you don't know your target platform at this point, writing native code over something cross-platform like React Native or Electron could be an expensive mistake. On the second, every time I've seen someone quote this essay at work, it has always been for a bet that has ended up problematic or at least mixed result. The first time I saw it was in a mildly heated debate about whether we should use React. I lost the argument and that org chose Knockout.js with JSPs instead. You can guess how expensive that "pragmatic" decision turned out. The second time was at a startup where the "boring technology" was - ironically - MongoDB. Everyone there had worked with Mongo and our only prior RDBMS experience had been with Oracle and PL/SQL. The result was a mess because noSQL stores only work when you have inflexible query patterns, which is the opposite of product iteration at a startup. So I am sceptical. If you know where your business should differentiate itself, and what pressures it will be under, choosing a technology should be - if not obvious, at least a process you can follow. Relying on proxies like "innovation tokens" feels to me like a mistake because it is, fundamentally, trying to replace strategic thinking with a points system.

gfodor 4y ago
> Relying on proxies like "innovation tokens" feels to me like a mistake because it is, fundamentally, trying to replace strategic thinking with a points system. No, it’s making it clear that there’s a scarcity you have to manage that is non-obvious: too many novel tech choices and you end up getting burned by the sum of all their risks leading to perpetual problems. If you have engineers literally allocating themselves a fixed number of tokens they don’t understand the talk.
- zero_shift 4y ago
  So why use any novel technologies, then? Why don't we use tech from the 1990s? Is it just neophilia? Or is it that tech companies, by their nature, are about automating new things by applying, building, leveraging new technology? And that they are invested in because people want to make a bet on those productivity multipliers?

adamnemecek 4y ago

This is such an uninteresting take. It's in the same category as "all programming languages are the same". I wonder where this comes from. Are all operating systems the same? Are all file systems the same? Are all databases the same? New tech generally tries to solve some problem. Maybe your project doesn't need that solution. Maybe you have been waiting for something to come along to solve that problem.

subtra3t 4y ago
The problem, is that the problems these "new techs" try to solve are usually problems that are not generally faced, or try to bring a new approach to a more general problem with already accepted solutions.
- adamnemecek 4y ago
  Which new tech with some adoption is not solving a problem?

5350-uiop-1130 4y ago

I think you need the bitterness and pessimism of 30 years experience to have good judgement. A lot of new tech is developed or managed by 20 somethings who just don't have that.

jb3689 4y ago
A lot of new tech is also spun out of large companies where the original ideas were piloted internally (see Kubernetes, Bazel, a number of distributed databases)
cheradenine_uk 4y ago
I was just thinking that I could likely make a reasonably accurate guess to commenters age based on their reactions to this article. But you trigger an interesting question. Frankly, part of my value to an organisation /is/ the accrued scar tissue from working with exciting technology; "choose boring technology" has us greybeards nodding along as at least half our job is about saying "no" to things - by being good at making the value judgements about when something shiny is worth it, and to be worried about those unknown-unknowns as you're gonna get the call when it breaks at 3AM on a weekend. But: We're clearly not learning from this. Maybe if we don't let people burn themselves they won't discover the stove is hot? Is this just the way of things, or a function of the fact that older engineers are steadily driven out into 'management', and the industry keeps re-inventing the wheel every 5 years?

nus07 4y ago

I don’t think you should either choose boring technology or adopt shiny new technology . It’s always in the middle and what your appetite for risk and business and financial situation is . For a business that can take risks by all means you should adopt new technologies because that’s what the future is . For ones with less risk appetite like large hospitals or banks you want boring technology until the shiny new tech has become more mature and resolved initial kinks at which point you should switch over otherwise risk being obsolete .

rossdavidh 4y ago

I began programming at a large institution that chose (for them) boring technology; they got good results, but eventually had to build almost everything themselves because the software world had moved on and left them behind. Later, I worked at a smaller company that let a young talent bring in a newer, more complex technology stack, made for solving problems at a scale they not only didn't have, but would never even aspire to reach. His reason was clearly that he wanted it on his resume; it took me a while to figure out that was his supervisor's reason for letting him do it. Both probably left soon after, leaving behind a higher maintenance load that would have helped them only if they reached a scale 1,000x bigger than there was any prospect of. These two cases (and several others like them) have convinced me that it is possible to screw this up in either of two directions. No doubt there is a good rule of thumb to determine how to get it right, but I haven't found it yet. The best I know of is, to be aware that it is very possible to get this wrong in either direction.

a-priori 4y ago
"Choose boring technologies" doesn't imply "... and then never change ever again even when it becomes obsolete and unsupported". That's where the first company went wrong. It means to choose technology components that are stable and boring (but still actively developed with a healthy community around them!). It also means to break this rule if and when that thing is important enough to your success that it makes sense to spend innovation points on it because it'll set you apart. But also recognizing that those instances are rare, and that's where good engineering judgment and leadership comes in.
- atoav 4y ago
  "Choose boring technologies" is one of those phrases that makes sense when it makes sense, unless it doesn't. I find the negative expression of the same idea much more fitting: "Don't choose technology purely out of exitement". In that negative version the word purely does the heavy lifting: If all you have as a reason to choose a thing is excitement it might be a bad choice unless you can afford a failed attempt. In reality very often the "more exciting" choice will also come with their own additional pros/cons. It might be that your exciting Rust-Webservice has a smaller community backing its components, but maybe the APIs of the few components you really interact with is such a joy to use that it will save you weeks over the Java equivalent, while giving you magnitudes faster startup times and decent testability. In programming there are so many angles to consider, that simplistic answers are rarely do reality justice. There is however the danger of wearing rose tinted glasses when weighing the cons of the more exciting solution.

dgb23 4y ago

> innovation tokens Aside: Sorry to be blunt but this is such a dumb term that distracts from some of the important lessons in this talk. The author confuses "innovation" with "novelty", "niche", "general familiarity" and so on. Choosing existing solutions has nothing to do with innovation. The innovation already happened. You're just integrating with it. But what about expertise, leverage, problem fit, cost, licensing, performance, bloat, implied workarounds, maintainability, community, attracting the right people and trust? What about simplicity? I think the bottom line here is to choose mastery and depth over novelty and breadth. Being really good at using very few orthogonal tools is a good thing. Spending more time on the abstraction layers above and below you rather than switching between arbitrary choices too. But these things have _nothing_ to do with how novel, niche or "innovative" a given tech choice is. That's just plain old conservatism, which can be an advantage or a disadvantage depending on what kind of work you're doing.

cassandratt 4y ago

Choose the appropriate tools for the job. I hate these idiotic posts that examine a sliver of a domain and think they have the answers to all of programming. It’s just naïveté on display, and this site eats it up.

pharmakom 4y ago

I much prefer Choose Simple Technology, where “simple” is as it is understood as in Rich Hickeys Simple Made Easy.

js8 4y ago

My rule of thumb is this: For the domain you work in, you CAN use cutting-edge technology. For things outside the product domain, use standard (boring, time-tested) technology to hedge risk. For example, when writing a DB, you might make use of a novel data structure, but don't use, for instance, an experimental parsing library.

skrebbel 4y ago

I feel like this article didn't age so well. It was written at the end of a decade long hype cycle when a lot of old ideas got replaced by new ones. A bunch of these new ideas (eg mongodb) went out of vogue, but a whole bunch simply got better and established. At the same time, a lot of previously boring technology caught up, so we now got to the point where formerly non-boring technology got more stable and established, and boring technology got, eh, less boring. Eg Java severely un-sucked itself as a language. And if you still don't like it, you can use Kotlin and still get a fantastic ecosystem, tooling, etc etc skipping all the reasons to choose boring tech. Postgres got all kinds of fancy new features, including indexable jsonb which lets it compete with lots of NoSQL DBs. And so on, and so forth. On the non-boring side, Go, Elixir, Rust, Redis all became stable, dependable technology choices that really aren't at all as risky as they used to be in 2015. Is Java more boring than Elixir? Sure, but is the Elixir ecosystem so tiny that picking it is a major risk? Definitely not. The gap between what used to be boring and not narrowed a lot. Of course there's still new non-boring tech, but somehow it all feels a bit less paradigm changing to me. Eg React turned front-end dev upside down. Vue and Svelte just iterate on its ideas a bit. Sure there's still some good ideas here. Maybe think twice before building a web app in 100% Rust, wasm-compiled on the frontend to a webgl based custom UI. But I don't think that's the kind of way-out-there stuff the authors of this article had in mind.

KronisLV 4y ago
> The gap between what used to be boring and not narrowed a lot. Of course there's still new non-boring tech, but somehow it all feels a bit less paradigm changing to me. What about new tech that's boring by design? To me, that kind of feels why Go succeeded: it didn't attempt to solve all of the world's problems, merely become a relatively simple language that one can pick up and be productive in reasonably quickly, while also having a decent amount of batteries included. Over the years, there have been relatively few major changes (generics come to mind, but those don't really break much old code at all) and it's remained somewhat stable/boring throughout the years.

asiachick 4y ago

Let's get concrete! What is boring tech in the context of creating an SPA website? A LAMP stack (seems too old and boring give that most SPAs want some form of real time updating) React? Is that old and boring yet or new and unproven? React with what (since react is just a framework for DOM manipulation Rails? Does that meet today's requirements? At the time it wasn't written for SPAs, was written for MPAs.

kaixi 4y ago
PHP + jQuery/Vue/Alpine + SQLite

dang 4y ago

Related: Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=30389591 https://news.ycombinator.com/item?id=30389591 - Feb 2022 (13 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=26211721 https://news.ycombinator.com/item?id=26211721 - Feb 2021 (361 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=25322651 https://news.ycombinator.com/item?id=25322651 - Dec 2020 (204 comments) Choose Boring Technology (2015) - https://news.ycombinator.com/item?id=23444594 https://news.ycombinator.com/item?id=23444594 - June 2020 (282 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246 - July 2019 (344 comments) Choose Boring Technology - https://news.ycombinator.com/item?id=9291215 https://news.ycombinator.com/item?id=9291215 - March 2015 (212 comments)

chaostheory 4y ago

This makes total sense from an organizational POV, but a lot of developers do resume or CV focused development whether or not people admit it.