5 ms·

"Choose boring technology" is important not because it's universally right. It's important because it combats a problematic bias in the tech industry. Individu

"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.
- travisgriggs 4y ago
  But “requirements” are hard. In a given organization everyone will have different opinions. Even more importantly, the same individual will have varying opinions based on their current context. What if one of your requirements is “retain talent because the longer they stay and know the business, the more valuable they are.” But boring those employees with the same old never change anything approach will drive them away. My biggest gripe with the choose boring technology mantra is that it often conflates with a sort of tech populism. Populism often creates short time wins for long term losses.
zero_shift 4y ago
I actually think the bias can go either way. Sometimes, technologists are suspicious of new practices and assume the motive is neophilia You can see this in McKindley's talk. Developers who want productivity improvements are just after "shiny things". Because they're stupid, like kids or animals, get it?
- peterhunt 4y ago
  It's possible that you and I have different experiences. But many times I've seen people at FAANG gunning for that coveted E6/Staff promo choose new technology even when unnecessary, because it's hard to find projects that demonstrate the skills needed for that promo. The context also matters. If you're working on a small team with low attrition, the cost of choosing new technology is low. If you're on a large team or in a high attrition environment, the costs for choosing a new, unfamiliar technology are astronomical.
- andrewmutz 4y ago
  > Technologists are suspicious of new practices and assume the motive is neophilia This is the opposite of what I've experienced
- subtra3t 4y ago
  I personally find that most developers (especially those in a web related field) tend to shift to newer technologies when there is very little reason to do so, and perhaps more importantly, be an evangelical today. Ask yourself this: do you seriously think that a company would benefit from switching stacks every few years, or sticking with a mature and battletested technology?
  - ratww 4y ago
    I find that this happens mostly due to career expectations. Gotta stay up to date to get the recruiters chasing you. But when everyone else is also up to date, gotta stay ahead and be an influencer/evangelist. > Ask yourself this: do you seriously think that a company would benefit from switching stacks every few years, or sticking with a mature and battletested technology? In my experience this is unfortunately situational, and depends heavily on who's answering. Someone who loves the current stack will say "don't change it". Someone who loves the next stack will say "yes burn it to the ground". Both of them, after doing a bit more self-reflection, will probably say "well, it depends, but probably not".
actually_a_dog 4y ago
Exactly. Where I work, we've explicitly chosen to "choose boring technology" in the parts of our stack that aren't key differentiators in our product. The idea goes back to the concept of "best practices" being essentially "what everybody else does," which essentially means "good enough, unless it's something that needs to be better than good enough." In essence, this has lead us to a philosophy that's very close to (but not quite) "AWS is our architecture 'standard library.'" We also define "boring technology" a little differently than the post does, I think. Basically, we think of it as "stuff that isn't going to page me in the middle of the night and wake me up." For us, because we're already on AWS, that tends to be AWS managed services, except for the services that directly provide functionality to our product, which we run containerized on EC2. Essentially, our comparison between AWS managed services and running some other service ourselves to meet the same need comes down to cost. If it costs less than about 3 engineers' salaries to run the AWS service, we're happy to hand off the pagers to them rather than wake up our engineers when those services get unhappy. We also apply this philosophy to our custom services. Right now, we have a monolithic web app that runs on Python + Flask + SQLAlchemy. So, by default, any new services run on Python + Flask + SQLAlchemy. Not FastAPI, not Django, not Rails and definitely not node.js. Python + Flask + PostgreSQL + SQLAlchemy, unless you have a convincing case for running something else. Not only is this extremely boring technology (Python has been around for ~30 years; Flask 12 years; SQLAlchemy 16 years; and Postgres -- who cares, we use it via RDS and let Amazon manage it), but we won't have to try and hire people who know Scala, for instance. We're also not above stealing large portions of our architecture, when appropriate. One good example is that we've essentially lifted the auth system for our new API from an example in one of the AWS blog posts. It works. We know we won't have to worry about it in the future. It's boring, and not a core feature of our product, so we don't want to have to care much about it. None of this isn't to say we don't have a lot of exciting stuff going on inside our product. We do. It's just that we have deliberately chosen for our non-core functionality to be boring and run on boring technology that's mostly managed by other people. I guess that's a little like us choosing to spend our "innovation tokens" wisely.

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.
travisgriggs 4y ago
But “requirements” are hard. In a given organization everyone will have different opinions. Even more importantly, the same individual will have varying opinions based on their current context. What if one of your requirements is “retain talent because the longer they stay and know the business, the more valuable they are.” But boring those employees with the same old never change anything approach will drive them away. My biggest gripe with the choose boring technology mantra is that it often conflates with a sort of tech populism. Populism often creates short time wins for long term losses.

zero_shift 4y ago

I actually think the bias can go either way. Sometimes, technologists are suspicious of new practices and assume the motive is neophilia You can see this in McKindley's talk. Developers who want productivity improvements are just after "shiny things". Because they're stupid, like kids or animals, get it?

peterhunt 4y ago
It's possible that you and I have different experiences. But many times I've seen people at FAANG gunning for that coveted E6/Staff promo choose new technology even when unnecessary, because it's hard to find projects that demonstrate the skills needed for that promo. The context also matters. If you're working on a small team with low attrition, the cost of choosing new technology is low. If you're on a large team or in a high attrition environment, the costs for choosing a new, unfamiliar technology are astronomical.
andrewmutz 4y ago
> Technologists are suspicious of new practices and assume the motive is neophilia This is the opposite of what I've experienced
subtra3t 4y ago
I personally find that most developers (especially those in a web related field) tend to shift to newer technologies when there is very little reason to do so, and perhaps more importantly, be an evangelical today. Ask yourself this: do you seriously think that a company would benefit from switching stacks every few years, or sticking with a mature and battletested technology?
- ratww 4y ago
  I find that this happens mostly due to career expectations. Gotta stay up to date to get the recruiters chasing you. But when everyone else is also up to date, gotta stay ahead and be an influencer/evangelist. > Ask yourself this: do you seriously think that a company would benefit from switching stacks every few years, or sticking with a mature and battletested technology? In my experience this is unfortunately situational, and depends heavily on who's answering. Someone who loves the current stack will say "don't change it". Someone who loves the next stack will say "yes burn it to the ground". Both of them, after doing a bit more self-reflection, will probably say "well, it depends, but probably not".

actually_a_dog 4y ago

Exactly. Where I work, we've explicitly chosen to "choose boring technology" in the parts of our stack that aren't key differentiators in our product. The idea goes back to the concept of "best practices" being essentially "what everybody else does," which essentially means "good enough, unless it's something that needs to be better than good enough." In essence, this has lead us to a philosophy that's very close to (but not quite) "AWS is our architecture 'standard library.'" We also define "boring technology" a little differently than the post does, I think. Basically, we think of it as "stuff that isn't going to page me in the middle of the night and wake me up." For us, because we're already on AWS, that tends to be AWS managed services, except for the services that directly provide functionality to our product, which we run containerized on EC2. Essentially, our comparison between AWS managed services and running some other service ourselves to meet the same need comes down to cost. If it costs less than about 3 engineers' salaries to run the AWS service, we're happy to hand off the pagers to them rather than wake up our engineers when those services get unhappy. We also apply this philosophy to our custom services. Right now, we have a monolithic web app that runs on Python + Flask + SQLAlchemy. So, by default, any new services run on Python + Flask + SQLAlchemy. Not FastAPI, not Django, not Rails and definitely not node.js. Python + Flask + PostgreSQL + SQLAlchemy, unless you have a convincing case for running something else. Not only is this extremely boring technology (Python has been around for ~30 years; Flask 12 years; SQLAlchemy 16 years; and Postgres -- who cares, we use it via RDS and let Amazon manage it), but we won't have to try and hire people who know Scala, for instance. We're also not above stealing large portions of our architecture, when appropriate. One good example is that we've essentially lifted the auth system for our new API from an example in one of the AWS blog posts. It works. We know we won't have to worry about it in the future. It's boring, and not a core feature of our product, so we don't want to have to care much about it. None of this isn't to say we don't have a lot of exciting stuff going on inside our product. We do. It's just that we have deliberately chosen for our non-core functionality to be boring and run on boring technology that's mostly managed by other people. I guess that's a little like us choosing to spend our "innovation tokens" wisely.