4 ms·

I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and

I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and feels sort of unserious. Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. For example, I may think "New" means untested, but is that true? What if a new project has Jepsen testing, a fuzzing suite, massive compute running tons of oracle tests, etc? I should just say "Choose well tested" instead of "Choose old" - lots of old software is very poorly tested. Maybe I think that "Old" implies better documentation, but does it? Lots of older projects have insane cruft and weird edge cases that are undocumented and accumulated over years. Why do we need a metaphor? Why is "innovation token" helpful? If you're incapable of evaluating a technology in terms of these properties, you aren't a serious developer and "boring" will not save you. Sit down, write our your requirements, determine candidate solutions, and choose them based on their fit. "Boring" means nothing, it's a vague proxy term. "Well tsted", "performant for our use case", "developers know it", etc mean something. > MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring. Literally every one of these has caused hilarious and disastrous failures for me in my career. But yep, boring. > If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. What if you know NodeJS really well? Or MongoDb? What if you have empirical, verifiable reasons for why they fit better? I'm a bit tired of "simple" and "boring" and other nonsense words in this field taking up the air in the room that should be spent evaluating solutions on their actual merits.

bcrosby95 2mo ago
This was written over a decade ago. I'd take it in that context. Lots of the tech they're talking about was being cargo culted en-masse. So yes, pick boring tech, defined as the tech you know the sharp edges of.
- insanitybit 2mo ago
  I don't think that context is relevant to my comment. I didn't say "in hindsight, those technologies are great!", I pointed out that "boring" is meaningless, and any meaning you attribute to it like "defined as the tech you know the sharp edges of" is better substituted in. That is, if someone said two sentences, I would only care about the second one: 1. "We should use this because it is boring" 2. "We should use this because we understand the sharp edges" I wouldn't care at all about (1) and I'd have a real conversation based on (2). Any productive conversation that starts with (1) immediately has to follow "can you clarify what that means", so the term is useless at best and thought terminating at worst.
  - tp3358 2mo ago
    Isn't this somewhat semantical? Boring implies a lot of the things you said, especially if it means your team's experience is largely pooled in a particular dev environment. Assuming most boring tech is ubiquitous, it's probably rare that your team, statistically, is deeply literate in some obscure tech - they most likely are experts in some definition of "boring". TLDR; #1 and #2 are essentially implying the same thing.
    - dwattttt 2mo ago
      insanitybit's point is that "boring" can imply those things, but it can imply other things too. If you have to bring the correct context to make the word make sense, and there's other contexts that could apply that don't make sense, the word isn't helping. You bringing the correct context is doing the heavy lifting.
      - tp3358 2mo ago
        I guess context clues and the way the post was written had obvious implications - that was my point. I do understand it leaves a little open to interpretation, which is the angle he decided to comment on.
  - dnautics 2mo ago
bravura 2mo ago
"boring" means familiar. It should have more known unknowns than unknown unknowns.
- insanitybit 2mo ago
  So then say that.
  - geodel 2mo ago
    Well its understood. Maybe your definition of explicitness is only met by things written like Principia Mathematica.
    - insanitybit 2mo ago
      If it's understood then it's pointless. I also reject that it's understood. I have no idea why you're talking about Prinicipia Mathematica as if I'm advocating for some sort of formal verification or extraordinary rigor as opposed to my suggestion that people just use their words and have reasons behind their decisions.
  - Gormo 2mo ago
    The article does say that. Explicitly. It's even got a picture of Donald Rumsfeld to help drive the point home.
    - insanitybit 2mo ago
      Then the word "boring" is pointless and the article is reductive.
i_like_robots 2mo ago
I see innovation as a guardrail against CV driven development. More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution - I remember more than a handful of projects failing (either undelivered or rewritten well under their expected lifecycle) around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn't take off and was a dead end. > What if you know NodeJS really well? Then you consider it boring. I'm sure Node and MongoDB were singled out by the author because at the time of writing they were still relatively new and undergoing periods of rapid development and change.
- insanitybit 2mo ago
  CV driven development is just as well guarded against by asking someone to justify their technical decisions based on the requirements and how the solution meets them. So "boring" does nothing to further that. > More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution It's linked today, people feel it's relevant today. This isn't a historic piece about how the tech industry used to be, people reference this post today. > around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn't take off and was a dead end. Yes, they should have had a discussion about their requirements and which technologies would have solved them. > Then you consider it boring. Then "boring" is useless and you should just say "I know this technology well and it maps to our use case well" and be able to justify that.
  - i_like_robots 2mo ago
    You seem to agree with the lecture/article but disagree with the title. However, it's influenced a lot of people for more than a decade and the snippy title might well have something to do with that.
    - insanitybit 2mo ago
      I don't agree with the article though and I dislike the influence it has had. I have seen engineers use "Boring" to justify "I know this technology" for situations where that technology is a bad fit. Conversations about technical solutions are bespoke, there is no one term that can or should be used to guide them.
geodel 2mo ago
Well your points are making sense in isolation whereas this article is making more sense in general. > I'm a bit tired of "simple" and "boring" and other nonsense words in this field... This is hilarious in sense millions more will be tired and exhausted by evaluating new and exciting technology endlessly appearing all the time. People go by these rule of thumbs which may not be perfect in every single case but they do increase success chances for even sub-par teams as opposed to "rigorously evaluating latest technology"
- insanitybit 2mo ago
  I don't think it's exhausting to determine if a solution fits your requirements and I don't think much about the people who would find it exhausting. I'm not suggesting some insane formal verification, but you really can't just answer basic questions about how technologies can address problems? Then what is your role? To choose mysql irrespective of requirements? > People go by these rule of thumbs which may not be perfect in every single case but they do increase success chances for even sub-par teams as opposed to "rigorously evaluating latest technology" Rule of thumb. And it's not a rule. It's a bias based on a vague term.
  - geodel 2mo ago
    Well mysql likely will turnout to be better choice than choosing "Cloud scale nosql DBs" when evaluators have rather limited hands-on knowledge about either of them.
    - insanitybit 2mo ago
      > Well mysql likely will turnout to be better choice than choosing "Cloud scale nosql DBs" when evaluators have rather limited hands-on knowledge about either of them. Obviously a straw-man, but also... justify it then? That's the point. You should be able to justify your position. "Cloud scale nosql db" doesn't tell me why you shouldn't choose it.
simonw 2mo ago
> What if you know NodeJS really well? Or MongoDb? Then they're not boring. Boring isn't a universal trait, it has to be evaluated within the context of your own team.
- insanitybit 2mo ago
  Then it's useless. If I have to take the context into account then I should be prepared to have a conversation about the requirements and how the technology fits it, which "boring" does not facilitate (and discourages).
  - simonw 2mo ago
    Weird take. It's clearly useful as a communication tool. You talk to your team, you say "Let's use boring technology. Read the essay, then we can discuss what boring technology means to us first."
    - insanitybit 2mo ago
      I obviously don't agree that it's useful as a communication tool though. Why not "Use the technology that's appropriate for our use case"? That seems radically better and doesn't suffer from weird misinterpretations or vague terms.
      - simonw 2mo ago
        Because people LOVE COMING UP with excuses to try a new technology under the basis that "this is appropriate for our use-case", and if you don't introduce a concept similar to innovation tokens you may find that six months later your project is combining three different unproven new technologies and doesn't actually work yet. Encouraging your team to be selective in where they place their new bets - and use "boring" aka already-understood technology for the bits that are not going to help solve unique problems - can help avoid expensive mistakes.
        2mo ago
marcosdumay 2mo ago
> For example, I may think "New" means untested, but is that true? The article answers this, and the answer is "no". New technology is one you don't know the details of. > determine candidate solutions, and choose them based on their fit That's quite hard to do for solutions that you don't know the details. You have an objection to something. It's clearly not to the article's point, though.
- insanitybit 2mo ago
  > That's quite hard to do for solutions that you don't know the details. That's a great thing to discuss when deciding on the technology. Maybe you should aim for solutions that you know well, or a solution that makes migrating away easy, or maybe you need to do some discovery work, etc. > You have an objection to something. It's clearly not to the article's point, though. It's an objection to the nature of the article itself - that technical decisions should work this way, that metaphors like "innovation tokens" are useful, that "boring" is a good proxy word.
moregrist 2mo ago
> I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" It’s a cute way of saying that you can only do 2-3 new things. The post is written for an engineer at a startup as a reminder that although it’s green field development, you only have so much runway, so it’s better to focus on what matters instead of trying some new tech because it seems cool. If you’ve ever had to estimate your stories/tickets/etc in “story points” or “T-shirt sizes” then “innovation tokens” is roughly the same. If you haven’t had to do that, you’ve lived a charmed life. > Engineers should understand requirements, risks, tradeoffs, and potential gains. Ideally. But I’ve worked with plenty of engineers who get far too excited by shiny new tech and overvalue its potential while undervaluing its risk. Hell, I’ve been that engineer in my misspent youth. The post resonates with many of us because it describes hard-won wisdom of our mistakes. > New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely. > What if you know NodeJS really well? Or MongoDb? What if you have empirical, verifiable reasons for why they fit better? In 2015, MongoDB was a dumpster fire (which is still kind of true) and node.js was still kind of new and had enough rough edges that most teams were probably better off choosing some other language/framework. > I'm a bit tired of "simple" and "boring" and other nonsense words in this field taking up the air in the room that should be spent evaluating solutions on their actual merits. “Boring” and “simple” are ways to convey that it’s good to be risk averse. It’s a bit of rhetorical flourish that helps drive the point home: choose what you work on carefully because you have limited runway and should spend that runway working on the problems that matter for your business, not new tech that’s orthogonal to it.
- deleted 2mo ago
  [deleted]
- insanitybit 2mo ago
  > It’s a cute way of saying that you can only do 2-3 new things. Why? What if doing 1 new thing saves you from having to do 3 old things? Why 2? Why 3? > The post is written for an engineer at a startup as a reminder that although it’s green field development, you only have so much runway, so it’s better to focus on what matters instead of trying some new tech because it seems cool. I am not suggesting that you do something "because it seems cool". I'm suggesting that you evaluate the costs and benefits of technology, and that "boring" is not sufficient nor helpful in that evaluation. > Ideally. But I’ve worked with plenty of engineers who get far too excited by shiny new tech and overvalue its potential while undervaluing its risk. I've worked with plenty of engineers who dismiss technology because it is "hyped" etc and then try to build systems on top of databases or other tools that were never designe for the use case and fail miserably. The issue in both cases is engineers not evaluating solutions correctly. "Boring" will not help. I have literally been in a meeting where "boring" and "innovation" tokens were the justification for a technology choice that failed miserably. More than one! > Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely. I'm not sure what you mean. There's is presumably some technical solution to the problem you want to solve. > In 2015, MongoDB was a dumpster fire (which is still kind of true) and node.js was still kind of new and had enough rough edges that most teams were probably better off choosing some other language/framework. I don't see why you couldn't justify not using Mongo or Node and then determine they aren't fits without saying "they aren't boring enough". In fact, I don't think either of those aren't boring in the sense that document databases/ nosql aren't particularly shocking concepts - the issue was, by far, the implementation. > “Boring” and “simple” are ways to convey that it’s good to be risk averse. They are very bad at this. > It’s a bit of rhetorical flourish I don't think rhetorical flourish should have much of a place in technical discussions. If you find yourself reaching for rhetorical flourish, you should ask yourself why you can't justify your position on its merits. > choose what you work on carefully because you have limited runway and should spend that runway working on the problems that matter for your business, not new tech that’s orthogonal to it. New technology may not be orthogonal to it, it may be critical.
dwattttt 2mo ago
It's the "don't eat processed food" of software engineering.
dzonga 2mo ago
I will say one of my career regrets was kinda being dogmatic about boring tech instead of being pragmatic e.g with new tech there was a period around 2016-17s when people were building stuff with Node.js | Mongo. but it was risky tech though I had experience in it & turned some of those opportunities down cz I wanted to work with boring ruby/swift(iOS stuff) lol. rookie mistake. fortunately the market made me wise up - you go where you're wanted.
frrlpp 2mo ago
You are confusing software with technology. Choose boring technology, not choose old software.
- insanitybit 2mo ago
  I'm not, the post is what adds fog to what should be clear and direct conversations about technical solutions as per their ability to solve a product concern.
dyauspitr 2mo ago
At this point, any new programming language or framework adds nothing. Name one paradigm shifting programming language or framework over the last 10 years that has made anything previously not possible possible or even significantly easier.
- cpursley 2mo ago
  Phoenix LiveView
- insanitybit 2mo ago
  That has nothing to do with anything.
watwut 2mo ago
> What if a new project has Jepsen testing, a fuzzing suite, massive compute running tons of oracle tests, etc? I mean, back in the real world of 2015, it does not have any of those things and we know it.
- insanitybit 2mo ago
  Back in 2015 neither did the "boring" ones cited in the article. The point is that you can at least talk about those things and evaluate them.
mexicocitinluez 2mo ago
Couldn't have said that last part better myself.
duckmysick 2mo ago
So what's your technology stack? Which criteria did you use when choosing it instead?
- insanitybit 2mo ago
  I don't have a technology stack. Do you just mean what am I using for current projects? At work we use Rust primarily for services. It was chosen because we're doing a lot of low level and performance sensitive work. The risk we discussed most was devs not knowing the language, which we decided to hedge against in various ways and accepted that risk. We use Postgres for a lot of data. We've used it a ton at the company and have a lot of expertise. It handles relational data well, Row Level Security helps us with our multitenancy goals, etc. We discussed some risks, like write load on the db, and have mitigations in place for that that I don't want to get into much. We use gVisor for isolation. This was a more novel pick for us but we had very strict security requirements and the only two options we considered viable were Firecracker and gVisor - we didn't want to require KVM/ hardware support so we went with gVisor and have been very happy with it. There was a sort of "bake off" to evaluate solutions here. In every case we simply determined our requirements based on product features we needed and decided what to use. Surely we'll regret making a decision eventually but we've had reasons for these decisions every step of the way.

bcrosby95 2mo ago

This was written over a decade ago. I'd take it in that context. Lots of the tech they're talking about was being cargo culted en-masse. So yes, pick boring tech, defined as the tech you know the sharp edges of.

insanitybit 2mo ago
I don't think that context is relevant to my comment. I didn't say "in hindsight, those technologies are great!", I pointed out that "boring" is meaningless, and any meaning you attribute to it like "defined as the tech you know the sharp edges of" is better substituted in. That is, if someone said two sentences, I would only care about the second one: 1. "We should use this because it is boring" 2. "We should use this because we understand the sharp edges" I wouldn't care at all about (1) and I'd have a real conversation based on (2). Any productive conversation that starts with (1) immediately has to follow "can you clarify what that means", so the term is useless at best and thought terminating at worst.
- tp3358 2mo ago
  Isn't this somewhat semantical? Boring implies a lot of the things you said, especially if it means your team's experience is largely pooled in a particular dev environment. Assuming most boring tech is ubiquitous, it's probably rare that your team, statistically, is deeply literate in some obscure tech - they most likely are experts in some definition of "boring". TLDR; #1 and #2 are essentially implying the same thing.
  - dwattttt 2mo ago
    insanitybit's point is that "boring" can imply those things, but it can imply other things too. If you have to bring the correct context to make the word make sense, and there's other contexts that could apply that don't make sense, the word isn't helping. You bringing the correct context is doing the heavy lifting.
    - tp3358 2mo ago
      I guess context clues and the way the post was written had obvious implications - that was my point. I do understand it leaves a little open to interpretation, which is the angle he decided to comment on.
- dnautics 2mo ago

bravura 2mo ago

"boring" means familiar. It should have more known unknowns than unknown unknowns.

insanitybit 2mo ago
So then say that.
- geodel 2mo ago
  Well its understood. Maybe your definition of explicitness is only met by things written like Principia Mathematica.
  - insanitybit 2mo ago
    If it's understood then it's pointless. I also reject that it's understood. I have no idea why you're talking about Prinicipia Mathematica as if I'm advocating for some sort of formal verification or extraordinary rigor as opposed to my suggestion that people just use their words and have reasons behind their decisions.
- Gormo 2mo ago
  The article does say that. Explicitly. It's even got a picture of Donald Rumsfeld to help drive the point home.
  - insanitybit 2mo ago
    Then the word "boring" is pointless and the article is reductive.

i_like_robots 2mo ago

I see innovation as a guardrail against CV driven development. More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution - I remember more than a handful of projects failing (either undelivered or rewritten well under their expected lifecycle) around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn't take off and was a dead end. > What if you know NodeJS really well? Then you consider it boring. I'm sure Node and MongoDB were singled out by the author because at the time of writing they were still relatively new and undergoing periods of rapid development and change.

insanitybit 2mo ago
CV driven development is just as well guarded against by asking someone to justify their technical decisions based on the requirements and how the solution meets them. So "boring" does nothing to further that. > More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution It's linked today, people feel it's relevant today. This isn't a historic piece about how the tech industry used to be, people reference this post today. > around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn't take off and was a dead end. Yes, they should have had a discussion about their requirements and which technologies would have solved them. > Then you consider it boring. Then "boring" is useless and you should just say "I know this technology well and it maps to our use case well" and be able to justify that.
- i_like_robots 2mo ago
  You seem to agree with the lecture/article but disagree with the title. However, it's influenced a lot of people for more than a decade and the snippy title might well have something to do with that.
  - insanitybit 2mo ago
    I don't agree with the article though and I dislike the influence it has had. I have seen engineers use "Boring" to justify "I know this technology" for situations where that technology is a bad fit. Conversations about technical solutions are bespoke, there is no one term that can or should be used to guide them.

geodel 2mo ago

Well your points are making sense in isolation whereas this article is making more sense in general. > I'm a bit tired of "simple" and "boring" and other nonsense words in this field... This is hilarious in sense millions more will be tired and exhausted by evaluating new and exciting technology endlessly appearing all the time. People go by these rule of thumbs which may not be perfect in every single case but they do increase success chances for even sub-par teams as opposed to "rigorously evaluating latest technology"

insanitybit 2mo ago
I don't think it's exhausting to determine if a solution fits your requirements and I don't think much about the people who would find it exhausting. I'm not suggesting some insane formal verification, but you really can't just answer basic questions about how technologies can address problems? Then what is your role? To choose mysql irrespective of requirements? > People go by these rule of thumbs which may not be perfect in every single case but they do increase success chances for even sub-par teams as opposed to "rigorously evaluating latest technology" Rule of thumb. And it's not a rule. It's a bias based on a vague term.
- geodel 2mo ago
  Well mysql likely will turnout to be better choice than choosing "Cloud scale nosql DBs" when evaluators have rather limited hands-on knowledge about either of them.
  - insanitybit 2mo ago
    > Well mysql likely will turnout to be better choice than choosing "Cloud scale nosql DBs" when evaluators have rather limited hands-on knowledge about either of them. Obviously a straw-man, but also... justify it then? That's the point. You should be able to justify your position. "Cloud scale nosql db" doesn't tell me why you shouldn't choose it.

simonw 2mo ago

> What if you know NodeJS really well? Or MongoDb? Then they're not boring. Boring isn't a universal trait, it has to be evaluated within the context of your own team.

insanitybit 2mo ago
Then it's useless. If I have to take the context into account then I should be prepared to have a conversation about the requirements and how the technology fits it, which "boring" does not facilitate (and discourages).
- simonw 2mo ago
  Weird take. It's clearly useful as a communication tool. You talk to your team, you say "Let's use boring technology. Read the essay, then we can discuss what boring technology means to us first."
  - insanitybit 2mo ago
    I obviously don't agree that it's useful as a communication tool though. Why not "Use the technology that's appropriate for our use case"? That seems radically better and doesn't suffer from weird misinterpretations or vague terms.
    - simonw 2mo ago
      Because people LOVE COMING UP with excuses to try a new technology under the basis that "this is appropriate for our use-case", and if you don't introduce a concept similar to innovation tokens you may find that six months later your project is combining three different unproven new technologies and doesn't actually work yet. Encouraging your team to be selective in where they place their new bets - and use "boring" aka already-understood technology for the bits that are not going to help solve unique problems - can help avoid expensive mistakes.
      - 2mo ago

marcosdumay 2mo ago

> For example, I may think "New" means untested, but is that true? The article answers this, and the answer is "no". New technology is one you don't know the details of. > determine candidate solutions, and choose them based on their fit That's quite hard to do for solutions that you don't know the details. You have an objection to something. It's clearly not to the article's point, though.

insanitybit 2mo ago
> That's quite hard to do for solutions that you don't know the details. That's a great thing to discuss when deciding on the technology. Maybe you should aim for solutions that you know well, or a solution that makes migrating away easy, or maybe you need to do some discovery work, etc. > You have an objection to something. It's clearly not to the article's point, though. It's an objection to the nature of the article itself - that technical decisions should work this way, that metaphors like "innovation tokens" are useful, that "boring" is a good proxy word.

moregrist 2mo ago

> I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" It’s a cute way of saying that you can only do 2-3 new things. The post is written for an engineer at a startup as a reminder that although it’s green field development, you only have so much runway, so it’s better to focus on what matters instead of trying some new tech because it seems cool. If you’ve ever had to estimate your stories/tickets/etc in “story points” or “T-shirt sizes” then “innovation tokens” is roughly the same. If you haven’t had to do that, you’ve lived a charmed life. > Engineers should understand requirements, risks, tradeoffs, and potential gains. Ideally. But I’ve worked with plenty of engineers who get far too excited by shiny new tech and overvalue its potential while undervaluing its risk. Hell, I’ve been that engineer in my misspent youth. The post resonates with many of us because it describes hard-won wisdom of our mistakes. > New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely. > What if you know NodeJS really well? Or MongoDb? What if you have empirical, verifiable reasons for why they fit better? In 2015, MongoDB was a dumpster fire (which is still kind of true) and node.js was still kind of new and had enough rough edges that most teams were probably better off choosing some other language/framework. > I'm a bit tired of "simple" and "boring" and other nonsense words in this field taking up the air in the room that should be spent evaluating solutions on their actual merits. “Boring” and “simple” are ways to convey that it’s good to be risk averse. It’s a bit of rhetorical flourish that helps drive the point home: choose what you work on carefully because you have limited runway and should spend that runway working on the problems that matter for your business, not new tech that’s orthogonal to it.

deleted 2mo ago
[deleted]
insanitybit 2mo ago
> It’s a cute way of saying that you can only do 2-3 new things. Why? What if doing 1 new thing saves you from having to do 3 old things? Why 2? Why 3? > The post is written for an engineer at a startup as a reminder that although it’s green field development, you only have so much runway, so it’s better to focus on what matters instead of trying some new tech because it seems cool. I am not suggesting that you do something "because it seems cool". I'm suggesting that you evaluate the costs and benefits of technology, and that "boring" is not sufficient nor helpful in that evaluation. > Ideally. But I’ve worked with plenty of engineers who get far too excited by shiny new tech and overvalue its potential while undervaluing its risk. I've worked with plenty of engineers who dismiss technology because it is "hyped" etc and then try to build systems on top of databases or other tools that were never designe for the use case and fail miserably. The issue in both cases is engineers not evaluating solutions correctly. "Boring" will not help. I have literally been in a meeting where "boring" and "innovation" tokens were the justification for a technology choice that failed miserably. More than one! > Yeah maybe, but unless you’re working on a problem that the tech directly solves, it’s pretty unlikely. I'm not sure what you mean. There's is presumably some technical solution to the problem you want to solve. > In 2015, MongoDB was a dumpster fire (which is still kind of true) and node.js was still kind of new and had enough rough edges that most teams were probably better off choosing some other language/framework. I don't see why you couldn't justify not using Mongo or Node and then determine they aren't fits without saying "they aren't boring enough". In fact, I don't think either of those aren't boring in the sense that document databases/ nosql aren't particularly shocking concepts - the issue was, by far, the implementation. > “Boring” and “simple” are ways to convey that it’s good to be risk averse. They are very bad at this. > It’s a bit of rhetorical flourish I don't think rhetorical flourish should have much of a place in technical discussions. If you find yourself reaching for rhetorical flourish, you should ask yourself why you can't justify your position on its merits. > choose what you work on carefully because you have limited runway and should spend that runway working on the problems that matter for your business, not new tech that’s orthogonal to it. New technology may not be orthogonal to it, it may be critical.

dwattttt 2mo ago

It's the "don't eat processed food" of software engineering.

dzonga 2mo ago

I will say one of my career regrets was kinda being dogmatic about boring tech instead of being pragmatic e.g with new tech there was a period around 2016-17s when people were building stuff with Node.js | Mongo. but it was risky tech though I had experience in it & turned some of those opportunities down cz I wanted to work with boring ruby/swift(iOS stuff) lol. rookie mistake. fortunately the market made me wise up - you go where you're wanted.

frrlpp 2mo ago

You are confusing software with technology. Choose boring technology, not choose old software.

insanitybit 2mo ago
I'm not, the post is what adds fog to what should be clear and direct conversations about technical solutions as per their ability to solve a product concern.

dyauspitr 2mo ago

At this point, any new programming language or framework adds nothing. Name one paradigm shifting programming language or framework over the last 10 years that has made anything previously not possible possible or even significantly easier.

cpursley 2mo ago
Phoenix LiveView
insanitybit 2mo ago
That has nothing to do with anything.

watwut 2mo ago

> What if a new project has Jepsen testing, a fuzzing suite, massive compute running tons of oracle tests, etc? I mean, back in the real world of 2015, it does not have any of those things and we know it.

insanitybit 2mo ago
Back in 2015 neither did the "boring" ones cited in the article. The point is that you can at least talk about those things and evaluate them.

mexicocitinluez 2mo ago

Couldn't have said that last part better myself.

duckmysick 2mo ago

So what's your technology stack? Which criteria did you use when choosing it instead?

insanitybit 2mo ago
I don't have a technology stack. Do you just mean what am I using for current projects? At work we use Rust primarily for services. It was chosen because we're doing a lot of low level and performance sensitive work. The risk we discussed most was devs not knowing the language, which we decided to hedge against in various ways and accepted that risk. We use Postgres for a lot of data. We've used it a ton at the company and have a lot of expertise. It handles relational data well, Row Level Security helps us with our multitenancy goals, etc. We discussed some risks, like write load on the db, and have mitigations in place for that that I don't want to get into much. We use gVisor for isolation. This was a more novel pick for us but we had very strict security requirements and the only two options we considered viable were Firecracker and gVisor - we didn't want to require KVM/ hardware support so we went with gVisor and have been very happy with it. There was a sort of "bake off" to evaluate solutions here. In every case we simply determined our requirements based on product features we needed and decided what to use. Surely we'll regret making a decision eventually but we've had reasons for these decisions every step of the way.