8 ms·

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

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?
  - camgunz 4y ago
    I get some of what you're saying, but a lot of your posts caricature OP's position. They're not saying "don't ever choose new technology" or "never upgrade your programming language" (e.g. staying on Java 6). They're arguing that there's a human dynamic that tends to focus on the benefits of new tech without acknowledging the costs and risks, and not accounting for that dynamic can be ruinous. Evaluating technology choices is hard. There are a lot of moving pieces. Sometimes it's 100% the right choice to use Django or Hugo; others it's 100% the right choice to use Nuxt.js. This presentation gives engineers tools to better evaluate the tradeoffs involved. It is in some ways a polemic, but to me that's just to make it an interesting presentation.
  - deleted 4y ago
    [deleted]
peterhunt 4y ago
"Choose boring technology" is important not because it's universally right. It's important because it combats a problematic bias in the tech industry. Individuals within an organization are strongly incentivized to choose exciting technology. Not only is exciting technology more fun, it's also a new thing you can put on your resume, and the implementation of it is often an opportunity to demonstrate the architecture and design skills that are necessary to get promoted at many places. As you've pointed out, "choose boring technology" is wrong in many cases. However, it gets trotted out so often because, before this essay, it was very hard to combat the "choose exciting technology" bias that permeated many engineering orgs (and still does to this day).
- nickelpro 4y ago
  > "Choose boring technology" is important not because it's universally right. It's important because it combats a problematic bias in the tech industry. Instead of combating a dumb bias with a dumb catch phrase, why don't we say the right thing? Choose the technology that fits your requirements. If you don't know your requirements, learn them, or remain flexible.
  - peterhunt 4y ago
    Sure but "choose boring technology" is the right default for an organization. I think any new technology brought into an organization comes with a cost and that cost needs to be justified.
  - ratww 4y ago
    Well, going with "technology that fits your requirements" is kinda how we got the problems that led to this article being written. New unproven tech will, more often than not, still fit the requirements perfectly.
  - fknorangesite 4y ago
    > a dumb catch phrase, It's not a catch phrase, it's the title of an article. Or if it is used as one, it's in reference to this. > why don't we say the right thing? We do. It's in the body of the article.
jonahx 4y ago
> This again... Yes, this again, because it is the single most important and common error developers make today. > The problems with boring technology are twofold. One, it's about rejecting newer tech on a bet you don't need their features. No, it's about rejecting newer, complex tech when you demonstrably don't need it, and the real reason it was chosen is that developers like shiny new toys that are cool because other developers are all talking about them.
- adamors 4y ago
- zero_shift 4y ago
  > developers like shiny new toys that are cool because other developers are all talking about them. I refer you to my other comment about the profound misanthropy behind "I don't understand why people want more productivity so I will compare them to children / animals"
  - jonahx 4y ago
    > I don't understand why people want more productivity My assessment is that "want more productivity" is, 90% of the time, a nice-sounding smokescreen for what is in fact neophilia. I'm making an empirical argument, not a philosophical one. It's based on personal experience with many devs. There is a massive bias toward trendy technologies, and they are rarely chosen for objective, research-based reasons. What you are reading as "profound misanthropy" is coming from hard-won experience: I have seen the disastrous consequences of these decisions, the developer-years of wasted time, and in some cases had to clean up the mess myself.
johnchristopher 4y ago
Pretty sure this submission follows from this post https://news.ycombinator.com/item?id=31558748 https://news.ycombinator.com/item?id=31558748 (in comment to the 2nd top entry on the front-page at the moment). So maybe it should be read in that context. Eg: which dryer to buy as a consumer, not which API framework a startup should invest into (even though there are overlap, of course).
5350-uiop-1130 4y ago
> I lost the argument and that org chose Knockout.js with JSPs instead. You can guess how expensive that "pragmatic" decision turned out. would have thought React was the boring or pragmatic option in this scenario...
- zero_shift 4y ago
  Not in late 2015, if you came from a Java background
  - gedy 4y ago
    Knockout on top of JSP in a Java shop in 2015? That's very reasonable. React was not a good choice for everyone, esp then.
macNchz 4y ago
> 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. This is an interesting one to me from the opposite side of the decision: I was at a young startup that was a very early adopter of React, and I felt like it slowed the team down at that time. Even though it eventually became dominant, the ecosystem had pretty limited tooling early on, and it seemed like our team spent a lot of time coming up with in-house solutions for things that were eventually solved by definitive libraries (e.g. Redux). From my point of view it had a pretty tangible impact on our time to market for some important features vs using something less shiny. I’m not sure I’d have chosen Knockout and JSP instead (though I was a fan of Knockout at the time for small projects and feel like Vue is a great spiritual successor to it), but the experience certainly colored my decision making in the years since.
- zero_shift 4y ago
  Knockout was an abject disaster. We almost immediately ran into performance problems. Coupled with its own limited ecosystem we had the same problems as you experienced with React, but ended up in a far worse place. I have reflected on what happened quite a bit and I can't think of any redeeming aspect of that technology choice. It really was the worst possible move and it was entirely motivated by the "boring is better" argument.
mostlylurks 4y ago
Boring technology is not necessarily the same thing as older tech. Lisp, for instance, is much older than Java, yet Java is clearly in the category of "boring" technology, whereas Lisp is quite the opposite despite its age. It seems that for tech to be "boring" means merely that it is a safe choice for the task at hand, a tool that will certainly do what needs to be done, with the kind of ecosystem and stability that leaves little room for the unexpected, for exploration. There is no significant uncertainty involved in the use of such technologies, which makes them "boring".
thomascgalvin 4y ago
> One, it's about rejecting newer tech on a bet you don't need their features. Not really. It's more a bet that the limitations of the new tech - bugs, missing or incorrect features, lack of support, etc - will outweigh the benefits of the new tech's 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. This is often provably true, because you can point to personal experience where an older tech has been good enough for a five year plan. I think PostgreSQL is the ur example of this. Every once in a while, a new hotness comes along, ready to dethrone Postgres. Monog was the one I got caught up in. Mongo was so much easier to use, from a developer's perspective. The install was easier, the API was easier, clearing out test data after each run was easier. I loved it. But it also wasn't ACID compliant. Oops. > 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. Terraform is seven years old. It's not new tech, it's a proven, industry standard. And that's kind of the unspoken assumption of this piece: if your focus is on production, let someone else play with new tech until it becomes old tech. Let them assume the risk. > The first time I saw it was in a mildly heated debate about whether we should use React. This essay isn't saying "don't use new tech," it's saying "use new tech responsibly," and "limit the number of unknowns in your production system." It's saying that "going fast" and "cool new features" needs to be balanced with "reliability" and "support." And React is also eight years old, so it isn't a new tech, either. It's one of, if the not, de facto standards. I don't know when your team had that conversation, but React is a tech that fits very comfortably into the "we know what sucks about it" category, and has for a few years now. So does NodeJS, which is on his slides as an example of spending an innovation token. Tech marches on. Our understanding of it advances. Stuff that was new becomes old, and stuff that's old becomes obsolete. This essay isn't saying "don't move forward," it's saying "don't pick something because it's new, pick something because you can prove that it will help you."

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?
- camgunz 4y ago
  I get some of what you're saying, but a lot of your posts caricature OP's position. They're not saying "don't ever choose new technology" or "never upgrade your programming language" (e.g. staying on Java 6). They're arguing that there's a human dynamic that tends to focus on the benefits of new tech without acknowledging the costs and risks, and not accounting for that dynamic can be ruinous. Evaluating technology choices is hard. There are a lot of moving pieces. Sometimes it's 100% the right choice to use Django or Hugo; others it's 100% the right choice to use Nuxt.js. This presentation gives engineers tools to better evaluate the tradeoffs involved. It is in some ways a polemic, but to me that's just to make it an interesting presentation.
- deleted 4y ago
  [deleted]

peterhunt 4y ago

"Choose boring technology" is important not because it's universally right. It's important because it combats a problematic bias in the tech industry. Individuals within an organization are strongly incentivized to choose exciting technology. Not only is exciting technology more fun, it's also a new thing you can put on your resume, and the implementation of it is often an opportunity to demonstrate the architecture and design skills that are necessary to get promoted at many places. As you've pointed out, "choose boring technology" is wrong in many cases. However, it gets trotted out so often because, before this essay, it was very hard to combat the "choose exciting technology" bias that permeated many engineering orgs (and still does to this day).

nickelpro 4y ago
> "Choose boring technology" is important not because it's universally right. It's important because it combats a problematic bias in the tech industry. Instead of combating a dumb bias with a dumb catch phrase, why don't we say the right thing? Choose the technology that fits your requirements. If you don't know your requirements, learn them, or remain flexible.
- peterhunt 4y ago
  Sure but "choose boring technology" is the right default for an organization. I think any new technology brought into an organization comes with a cost and that cost needs to be justified.
- ratww 4y ago
  Well, going with "technology that fits your requirements" is kinda how we got the problems that led to this article being written. New unproven tech will, more often than not, still fit the requirements perfectly.
- fknorangesite 4y ago
  > a dumb catch phrase, It's not a catch phrase, it's the title of an article. Or if it is used as one, it's in reference to this. > why don't we say the right thing? We do. It's in the body of the article.

jonahx 4y ago

> This again... Yes, this again, because it is the single most important and common error developers make today. > The problems with boring technology are twofold. One, it's about rejecting newer tech on a bet you don't need their features. No, it's about rejecting newer, complex tech when you demonstrably don't need it, and the real reason it was chosen is that developers like shiny new toys that are cool because other developers are all talking about them.

adamors 4y ago
zero_shift 4y ago
> developers like shiny new toys that are cool because other developers are all talking about them. I refer you to my other comment about the profound misanthropy behind "I don't understand why people want more productivity so I will compare them to children / animals"
- jonahx 4y ago
  > I don't understand why people want more productivity My assessment is that "want more productivity" is, 90% of the time, a nice-sounding smokescreen for what is in fact neophilia. I'm making an empirical argument, not a philosophical one. It's based on personal experience with many devs. There is a massive bias toward trendy technologies, and they are rarely chosen for objective, research-based reasons. What you are reading as "profound misanthropy" is coming from hard-won experience: I have seen the disastrous consequences of these decisions, the developer-years of wasted time, and in some cases had to clean up the mess myself.

johnchristopher 4y ago

Pretty sure this submission follows from this post https://news.ycombinator.com/item?id=31558748 https://news.ycombinator.com/item?id=31558748 (in comment to the 2nd top entry on the front-page at the moment). So maybe it should be read in that context. Eg: which dryer to buy as a consumer, not which API framework a startup should invest into (even though there are overlap, of course).

5350-uiop-1130 4y ago

> I lost the argument and that org chose Knockout.js with JSPs instead. You can guess how expensive that "pragmatic" decision turned out. would have thought React was the boring or pragmatic option in this scenario...

zero_shift 4y ago
Not in late 2015, if you came from a Java background
- gedy 4y ago
  Knockout on top of JSP in a Java shop in 2015? That's very reasonable. React was not a good choice for everyone, esp then.

macNchz 4y ago

> 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. This is an interesting one to me from the opposite side of the decision: I was at a young startup that was a very early adopter of React, and I felt like it slowed the team down at that time. Even though it eventually became dominant, the ecosystem had pretty limited tooling early on, and it seemed like our team spent a lot of time coming up with in-house solutions for things that were eventually solved by definitive libraries (e.g. Redux). From my point of view it had a pretty tangible impact on our time to market for some important features vs using something less shiny. I’m not sure I’d have chosen Knockout and JSP instead (though I was a fan of Knockout at the time for small projects and feel like Vue is a great spiritual successor to it), but the experience certainly colored my decision making in the years since.

zero_shift 4y ago
Knockout was an abject disaster. We almost immediately ran into performance problems. Coupled with its own limited ecosystem we had the same problems as you experienced with React, but ended up in a far worse place. I have reflected on what happened quite a bit and I can't think of any redeeming aspect of that technology choice. It really was the worst possible move and it was entirely motivated by the "boring is better" argument.

mostlylurks 4y ago

Boring technology is not necessarily the same thing as older tech. Lisp, for instance, is much older than Java, yet Java is clearly in the category of "boring" technology, whereas Lisp is quite the opposite despite its age. It seems that for tech to be "boring" means merely that it is a safe choice for the task at hand, a tool that will certainly do what needs to be done, with the kind of ecosystem and stability that leaves little room for the unexpected, for exploration. There is no significant uncertainty involved in the use of such technologies, which makes them "boring".

thomascgalvin 4y ago

> One, it's about rejecting newer tech on a bet you don't need their features. Not really. It's more a bet that the limitations of the new tech - bugs, missing or incorrect features, lack of support, etc - will outweigh the benefits of the new tech's 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. This is often provably true, because you can point to personal experience where an older tech has been good enough for a five year plan. I think PostgreSQL is the ur example of this. Every once in a while, a new hotness comes along, ready to dethrone Postgres. Monog was the one I got caught up in. Mongo was so much easier to use, from a developer's perspective. The install was easier, the API was easier, clearing out test data after each run was easier. I loved it. But it also wasn't ACID compliant. Oops. > 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. Terraform is seven years old. It's not new tech, it's a proven, industry standard. And that's kind of the unspoken assumption of this piece: if your focus is on production, let someone else play with new tech until it becomes old tech. Let them assume the risk. > The first time I saw it was in a mildly heated debate about whether we should use React. This essay isn't saying "don't use new tech," it's saying "use new tech responsibly," and "limit the number of unknowns in your production system." It's saying that "going fast" and "cool new features" needs to be balanced with "reliability" and "support." And React is also eight years old, so it isn't a new tech, either. It's one of, if the not, de facto standards. I don't know when your team had that conversation, but React is a tech that fits very comfortably into the "we know what sucks about it" category, and has for a few years now. So does NodeJS, which is on his slides as an example of spending an innovation token. Tech marches on. Our understanding of it advances. Stuff that was new becomes old, and stuff that's old becomes obsolete. This essay isn't saying "don't move forward," it's saying "don't pick something because it's new, pick something because you can prove that it will help you."