
Choose Boring Technology (2015) - dpcx
https://mcfunley.com/choose-boring-technology
======
nine_k
I still think that "boring" is a wrong word.

Choose the technology you know in and out, and are immediately productive
with.

Choose the technology which is sure to be around in 5-7 years, preferably
10-15.

Choose the technology for which you are comfortable hiring the next 15
engineers.

This does not mean that you need to choose something unpleasant, unergonomic,
or ancient. Neither does it mean that you need to choose exclusively among the
top 5 most used in the field.

The key thing here is to _avoid surprises_ , unknown unknowns. You won't have
the time to learn from a novice level while building a new company.

A number of wildly successful MVPs were implemented with obscure (or then-
obscure) technology which authors knew very well, and which boosted their
productivity. ViaWeb was written in Lisp. YouTube was (and still largely is)
written in Python, way before it was cool and well-known. The initial Rust
compiler was written in OCaml.

~~~
kitd
> YouTube was (and still largely is) written in Python, way before it was cool
> and well-known.

I agree with you on just about everything, but python was well-known well
before YT. Django was a staple of the early web.

~~~
cmrdporcupine
It's funny to call Django the "early web" when it first came out in 2005. That
is really not early at all. Especially when you consider Rails, etc. predates
that.

I was an early Python adopter (1995/1996) and could not for the life of me
find anybody who would consider letting me use it in 'mainstream' commercial
software projects. Then all the sudden about 10 years ago it exploded in
popularity big time.

But I'd moved on to working on other things by then, I no longer enjoy writing
in Python.

Wow, this sounds like the classic "I was into that band before they popular"
indie snob, hah!

~~~
the-dude
Wikipedia says Rails was released in Dec 2005.

~~~
ghc
Rails was popular before anyone ever heard of Django. Rails jobs were already
common when it reached 1.0 at the end of 2005 (In early 2006 a law firm
offered me $30 to do rails work as a summer job off campus). Django took
another couple years before reaching 1.0, though I did do work for some early
adopters (0.95) circa summer 2006.

~~~
ikeyany
I think "early web" here refers to the popular technology used between
1995-2005.

------
l0b0
As relevant as ever. It's fascinating how big web stacks are these days, even
for small-to-medium sites: various combinations of at least one styling
language (SASS/LESS/CSS), frontend framework (Angular/React), frontend
language (JavaScript/TypeScript/Node.js), backend framework
(Django/Express/Spring/Rails) backend language (Python/Ruby/PHP/Perl/Java),
and message bus (ZeroMQ/Redis/RabbitMQ). That's just the frontend and backend.
Then there's infrastructure: pick at least _three_ infrastructure as code
components (Puppet/Chef/Ansible/k8s/Docker/Docker
Compose/VirtualBox/WMWare/heaps of shell scripts), at least two web servers
(Apache/nginx/traefik/your language's built-in server), and at least two TLS
certificate providers because someone's nervous about moving everything to
Let's Encrypt. I'm well aware that these don't have identical feature sets,
but that's the point of the article: _choosing a small and boring set of
technologies is an advantage, not something to be ashamed of._

~~~
gavinray
I don't know that necessarily correct.

Previous startup I was at had a stack like this:

\- Frontend: Vue + Typescript

\- Android/iOS App: Vue (NativeScript/Capacitor) + Typescript

\- Backend: Node + Typescript

\- Database: Postgres

\- Deployment: Everything in Docker containers

I know of a lot of places taking similar stances where the frontend and mobile
apps are done in this way (IE React and React Native) and then you get
Javascript/Typescript on the backend as well, so the entire stack is just
JS/TS the whole way through with a single UI/design language.

It was really easy to hire developers this way and the transferable skills
were high.

However you look at it, this is sort of the deal with JS these days. From a
productivity and development velocity perspective, it's really difficult to
rationalize using other technologies when you can just holistically build your
entire stack in one JS/TS UI framework for the clients (or Flutter, nowadays)
and then JS/TS on the backend too.

This is why I'm mentally shoehorned into using Typescript for everything. I
enjoy it a lot, but there are other languages I enjoy too, it just doesn't
make as much sense to throw them in the mix because then you've increased
technical complexity and made it that much more difficult to source talent.

~~~
choeger
You basically have arrived where lisp was some decades ago. Logical next steps
are to write the OS and the editor and the VCS in JavaScript.

However, at some point you will have a look into your myriad of nodejs
dependencies and see with horror that they rely on C++ extensions. Then you
learn that your precious stack is just a GCC upgrade away from not building
anymore. And noone in your company even remembers what that is, a C++ compiler
flag.

~~~
AmericanChopper
Whether you end up with a hellish dependency tree is more up to the developer
than the language. I’d say the only reason this is more common in node
projects than it is in other languages is because dependency management in
other languages is more tedious, so the barrier for introducing new
dependencies is higher.

All of my node projects have had rather tidy dependency trees. It’s also been
quite easy for me to use popular packages. If something breaks and hundreds of
thousands of devs are impacted by it, it’s going to get fixed pretty quick.
Which has been my experience in the rare occasions that in of my dependencies
has broken, it’s been fixed before it even had a chance to impact me.

~~~
randombytes6869
Trust me, its the lack of standard library. Python and Java are both
"batteries included" . You can write apps decently with just 5-10 dependencies
if you want. Every JS app I've worked on has like 10-20X the dependencies of
projects written in languages with a good standard lib

~~~
scottlocklin
> Trust me, its the lack of standard library.

It's almost certainly not, as R has plenty of batteries, and young nitwits in
the Hadleyverse are writing preposterous node-like dependency graphs. It's
fashion, and it should be curb-stomped.

~~~
dahauns
I don't see how R of all languages is a useful counterexample.

It's as far a way from a general-purpose language as it can get while
technically still being one, in both scope and intended use/audience.

~~~
scottlocklin
It's a useful counterexample because the problem didn't exist for the 20 years
before legions of nodejs bros descended upon it and bestowed upon us the mess
of hot garbage it is today. At this point, there is an entire half of the
ecosystem which is unusable unless you drink the 400 dependency kool aide.

------
leonardteo
Getting vulnerable here for a sec and hoping that others can add their
thoughts. I struggle with this. As a small-ish, bootstrapped business, the
issue I commonly run into is developer retention. If we stand our ground and
choose boring technology because we have limited innovation tokens and can't
afford to waste them, there's the flight risk of those devs who really want to
work with those new technologies. And this is real. I have dev friends who
have left great jobs just because they wanted to move to some new tech and
their company simply wasn't ready for the change yet.

In the past I have been told that I "don't trust developers" (despite being
one myself), and it has nothing to do with that. It's that some of us are left
with the consequences of those decisions and having to maintain those NIH-
riddled skeletons in the closet when those individuals leave - and the next
person comes along, finds the skeletons and we end up having to
rewrite/reimplement that whole part of the system.

Creating an environment where we can thrive and be creative is really
challenging. We've implemented the 20% time now where everyone in the company
has 1 day a week to just experiment and do whatever they want, just to give
the breathing room to be creative and try some of these new technologies. We
finally got there. But for years, we just couldn't afford to do it as we were
in survival mode.

But the retention issue is still a big one. I feel the tension between having
to empower people to make decisions that are for the greater good of the
business, while balancing that those people can (and will) leave at any time
and not face the consequences of those decisions.

Curious to hear thoughts.

~~~
tomc1985
Can I be honest? I fucking hate developers. We're like magpies of the worst
variety. How many times have I had to argue against bringing in ${NEW_TECH} or
${NEW_TECHNIQUE} because it would be more trouble than its worth. No, it
doesn't look as cool engineering-wise, and yes, our work may be a little
harder because of it. But then they win the argument and we implement it and
hey! Those problems I told you about? They're real! And if they had done it my
way we could have moved on to the next thing and not had to worry about this.

Fuck the latest thing. Fuck resume driven development. Fuck magpies. Choose
the boring path. Fuck developers!

The worst thing we do is obsess over the latest, coolest tech. Everyone is
stepping on their brothers and sisters in this field because they want to be
the loser that invented ${NEW_TECH}. We spend so much time optimizing for
'developer happiness' (a.k.a. the new shiny thing) that we forget about
architecture.

I am so sick of this field.

~~~
metrokoi
Why would you say something so controversial yet so brave?

Developers may be the least humble type of engineers. There are many great
things that we do, but we need to be taken down a peg every once in a while.
Many developers are forced into this mindset out of fear of our marketable
skills being made obsolete so I understand why many do this, and it is a
compounding problem. Developers seek out jobs with the shiny new technology or
push for their company to adopt it to be able to show that technology on their
portfolio, then there are fewer positions with the boring but reliable
technology and even more are forced to adopt the new technology.

~~~
tomc1985
Is that fear real though? I mean there are still job listings for VBA or
ColdFusion engineers if that's really your thing.

I think our problem (and my our, I mean American) is that we are too obsessed
with tech. This is coming from someone who grew up obsessed with computers,
and not just writing code. You can tell this is true from looking at our ads,
which are always touting the shiniest newest technological marvels. Even
beauty products -- they sound so sciency without actually saying anything.
Tech is our dogwhistle.

~~~
splintercell
My father-in-law who is a 58 year old software developer feels stuck at his
current job because he has spent so much time on old and archaic technology
that he doesn't feel confident enough to be able to go out there and get a new
job in case he's laid off.

Personally speaking I spent far too much time working on a certain technology
for four years and I felt trapped because getting a new job was difficult in
new technologies.

There are clearly some Evergreen Technologies such as C/C++, but there are a
lot of Technology switch don't land in that category and they evolved fast (js
ecosystem for instance).

------
semicolonandson
I've boot-strapped and lived from a web-application for over ten years, some
of which have involved less than one day per month's worth of work. I credit
this to boring technologies.

Looking back, the best technical decisions were:

\- using an SQL database with lots of constraints and foreign keys and
indexes. It's like typing for data.

\- emphasis on shell scripts and leaning on UNIX features (since these
continue working in ten years rather than being abandoned)

\- deleting as many libraries and dependencies as practical (over a ten-year
time frame, 80% will disappear or change in ways that require huge mental RAM
on your behalf)

\- a preference for paying for hardware to solve performance issues (vs.
complicating the code with fancy solutions)

For anyone interested, I go into more detail in this video
[https://www.youtube.com/watch?v=rQegYUsU7ec](https://www.youtube.com/watch?v=rQegYUsU7ec)

~~~
theshrike79
And vendor your dependencies if at all possible, that one library/tool you
were using might just disappear of the internet.

It will still work in 10 years if your toolchain hasn't changed much.

------
javajosh
SPAs (single page applications) aren't boring yet. we really don't know how to
do this well, as a community, and the cambrian explosion of JavaScript tech is
almost all around trying to make this extremely un-boring application style
more boring.

The SPA is a gateway drug to spending lots and lots of innovation tokens,
more, really, than almost any dev team can afford. For example, I would
consider each of Webpack, PostCSS, TypeScript, React, Redux, RxJS, to be
rather exciting, and that's only a few of the exciting parts of a mature SPA
project. And of course this doesn't touch REST, GraphQL, CI/CD, testing,
metrics, telemetry and all the other excitement.

So, yeah, I would say that if you take the article seriously for a webapp,
you'd limit yourself to a really boring Java (8) server-side architecture
using Jetty, JSP, Spring, a service layer, over Postgres. Maybe an nginx proxy
if you want to get a little spicy and have good SSL and static serving
performance, and an option for simple load balancing later. Oh and the only
provisioning you get to do is individual VPSs or even better, bare metal on
prem servers! Git and Jenkins is probably boring enough to use, though.

But yeah, no Docker, K8s, OpenShift, no AWS other than EC2 and maybe S3.
Probably no CloudFlare. Google Analytics, sure, but only if you don't care
about your users privacy. Sentry is too exciting.

And then on the HTML side I'd argue that your templates should produce plain
old HTML5, CSS3 and ES6. No transpilation, no source maps. No official support
for IE 11. And even for those languages you can cut out the most exciting
features. Do you _really_ need the "class" or "new" keywords in ES6? For JS
modules, use the boring, built in browser module system (you knew it had one,
right?![1])

1 - [https://caniuse.com/#feat=es6-module-dynamic-
import](https://caniuse.com/#feat=es6-module-dynamic-import)

~~~
baron816
React has been around for 7 years. ES2015 has been around for 5 years.

React has become the de facto lingua franca for front end development. Could
you imagine some CTO or technical lead saying, "We're not going to use React
because it's too new and unproven." React has proven itself. Facebooks has
100K+ components. There are no unknowns there. Using jQuery or vanilla JS
instead would be way more problematic and have more overhead than using
something more experimental like Elm or ReasonML.

You should almost never use classes in JS, but when you do, they're much
easier to work with and understand than defining properties on the prototype.
The "new" keyword has been around since almost JS's inceptions (it's available
in IE 3, which came out in 1996).

Some of your technologies require no learning to start using (PostCSS). Some
can require a whole new mental model/programming paradigm, but can be
incredibly useful if used sparingly and in the right places (RxJS). And some
things you just need to do to not have a garbage application (testing).

Look, just make assessments as to what your needs are, what are common
practices, what your current team is capable of being productive with, and
what you're going to be able to hire from.

~~~
JamesBarney
Despite React being around for 7 years, it still seems slower to develop,
slower in performance, and buggier than an equivalent SSR app.

Despite having a couple years more experience in React than SSRs, I can knock
out a 10 page web app with an SSR framework from scratch in a day (security,
frontend, backend, data schema, deployment) but it takes me a couple more to
knock out the same app in React. (Crud/Search/Reporting app)

*Not counting certain types of highly interactive apps (like a Word Processor) which React excels at.

~~~
arcturus17
I’m in the same boat, SPA feels slower to develop than SSR to me, despite
being fairly more experienced in SPA.

However, I find it hard to justify choosing SSR for new projects anymore
because:

\- React makes certain _basic things_ (eg, fetching data, auth) more complex
than in SSR, but the overall experience is weirdly addictive and exhilarating
at times, especially component reusability on a well set up project.

\- My clients love it. I am 100% in the camp of “users don’t give a shit how
the sausage is made”, but I constantly get praise on how “smooth” the UX
feels. I know there are SSR technologies (eg Turbolinks) that can emulate
this, but at this point I’m having a hard time justifying learning them
properly and risking missing out on that maybe superficial, but addictive,
customer praise.

\- It is indeed what I know best, so what the hell...

I believe a competent web developer should know both SPA and SSR and apply
what best fits the requirements at hand, but I can also appreciate why devs
form biases one way or the other and how this has become a hotly contested
topic, and I think we may still be in the same spot in three to five years.

~~~
nthj
Turbolinks takes a day to learn, tops, and then you just build more SSR and it
continues to work. And the abstraction rarely leaks.

------
peferron
Also: please, please pay attention to the fundamental design decisions that
underpin the technology you're choosing!

Set aside the GitHub stars, contribution graphs and HN reviews, and boil the
tech down to its fundamental principles. Then ask yourself how a perfect
implementation of that design would solve your problems. It it solves them
well, you're golden as long as the project is reasonably healthy. If it
doesn't solve them well, you might be setting yourself up for serious pain
down the line, and need to make a very conscious choice about whether the
short-term benefits of that technology choice are worth it, and how an
eventual migration to a better-fitting design would look like.

------
archived22
Job description these days become reflection of complexity in new age tech
stack. Know C++/Java/Scala/Enter_Your_Lang_Here with python and
React/Angular/Blah/Blah with Big Data Technologies - Hadoop, spark, etc. with
Docker/K8 and with Azure/GCP/AWS.

It is time consuming process to become expert of one thing, requires couple of
years of continuous focus.

I don't know How many people are actually expert of all these and how they are
going to perform when some issue pop up in production. Try that judging it
30-to-60 minutes of interview.

~~~
onion2k
I think this is largely representative of the real problem in web dev - the
tech has changed, the complexity has grown, and yet the expectation that a web
app is still something one person can build on their own using all the modern
approaches hasn't changed.

You can still make something that works on your own, but not using _all_ the
new tech. You have to compromise somewhere. The notion of "full stack" devs is
long gone. Making modern web apps is a team sport. You literally can't be an
expert in everything you need to build a robust, scalable, fast, accessible
web app anymore.

~~~
archived22
Another drawback of complex stack bites those people who have idea and money,
but try to get product done through consultancy because they lack tech skill
or does not have enough experience.

They read lot of 'buzzword' on the internet or heard them from their tech
friend and ask for everything i.e. Microservice Architecture and cloud and all
and etc. since beginning. Resulting in unnecessary huge team and tech
complexity. An idea or poc which could had been easily done and tested in
market with small techstack/small team. No wonder lot of these products fail.

~~~
RNCTX
It seems to me that simple devops decision making is becoming a forgotten
skill outside of devops pros due to separation of concerns, whereas 15 years
ago everyone knew how to install Linux or a BSD, set up required compilers and
virtual environments, set up Apache or Nginx, set up a database along with
database admin tools, etc.

Wasn’t any Ansible then, either, you had to write your own damn scripts.

~~~
onion2k
The _entire reason_ PHP grew so wildly in popularity was because hosting
providers made it so you could just FTP a file with a .php extension to a
server and it ran. Apache was the default web server for shared providers
because you could do per account config like url rewriting by uploading a
.htaccess file. Virtually no one was configuring their own servers or
installing Linux on bare metal for websites.

~~~
wpietri
That was a big reason, but I think another key choice was that the output
format (HTML) and the input format (PHP) could be pretty close. If you were 15
and wanting to make a dynamic webpage, you'd look at an existing web page,
copy it, and change one bit. PHP made that easy. The next change and the
change after that were easy too.

In contrast, competing technologies started out with, "OK, learn computer
science. Now learn how HTTP works. And then learn CGI. And some Unix. And then
you can do 'Hello, World.'"

The funny part for me is that a lot of us in the latter camp didn't learn
computers that way at all. We started out with BASIC:

    
    
        10 PRINT "Onion2K is cool!"
        20 GOTO 10
    

It had the same immediacy as PHP. The ease of making something happen was what
drew us in. But somehow we forgot that. While also saying, "Here's something
that will touch everybody on the planet. Let's all use it!"

------
whymauri
Prior discussion from when the blog was originally written:

[https://news.ycombinator.com/item?id=9291215](https://news.ycombinator.com/item?id=9291215)

A related page I recall seeing on HN last summer:

[http://boringtechnology.club/](http://boringtechnology.club/)

------
nickysielicki
One of the more frustrating things is that you can have a team that reads this
article and all agree about the goal but disagree about what is actually
boring and safe and worth doing.

There are a lot of people who confuse “boring” with “well-known”, and they’re
not the same thing.

Example: you decide to write C++, but the C++ you write looks a lot like C99.
You rationalize it as though you’re avoiding the overhead of all that
nonsensical modern C++ and doing the simpler and thus more-boring thing. In
reality: you’re writing shitty C++.

For the technology you choose, you should buy into it. Full stop. Don’t half-
ass it.

~~~
hamilyon2
Your example is controversial. What if that C99 coding style is company-wide
accepted and everyone is comfortable with it. On contrary, newer, more shiny
thing, like c++20 is not supported in tools and adds significant mental
overhead.

------
praveen9920
We learned this lesson the hard way. A few years back, for a start-up, we
picked angular 2.0 as our choice for frontend stack, when it is released.
Though it was fun to develop it, We faced a lot of unknowns and issues to
finally ship it.

Too many changes for each version, The bundle size was too big. Angular SPAs
were not great for SEOs etc. We ended up missing the shipping deadline by a
couple of months.

When you really want/have to `ship it`, pick any technology you and your team
have delivered something before.

When you have time to explore, pick any new shiny technology, and concentrate
on learnings.

~~~
ngngngng
I'm literally browsing hacker news right now to procrastinate work on an
Angular task. I can't think of a less boring technology, I've been writing it
for a couple years and it's still not simple to work with.

~~~
praveen9920
Ever tried iconic? It may still feel boring but it makes things easier when
developing.

~~~
xtracto
I like ionic a d it deffinitely is better than plain Angular. But Ionic is
VERY immature technology: they keep moving the goal post and changing things.
The latest version again changes crap with the replacement of Cordova.

And if you search their forums on how to do something (like take a video in
mobile and then showing it on the ui) it depends on each version and there are
no clear answer.

~~~
praveen9920
I wouldn't call them immature, they could probably be called fast paced.

It might help if you stick to one version until shipping something meaningful

------
scotty79
I think the problem is that not all programmers are motivated by successfully
building things.

Lots of us are motivated by learning things, and some are motivated by
investigating and solving problems when things don't go the way they supposed
to.

If you pick a 'boring' technology, you have less of those two things, and you
are stuck with boring process of developing one feature after the other with
boring technology until sufficient number is developed and you can go do
something more interesting.

~~~
non-entity
> I think the problem is that not all programmers are motivated by
> successfully building things.

> Lots of us are motivated by learning things, and some are motivated by
> investigating and solving problems when things don't go the way they
> supposed to.

I kinda realized this about myself recently, and now I'm wondering if I need
to leave the field.

~~~
asddubs
just switch to doing javascript

~~~
scotty79
That's what I did.

But in all seriousness. Software development does not only need builders.
Builders build stuff well but at some point they make mistakes or overestimate
their knowledge of technology. Then obsessive learners and investigators are
godsend.

Just know your limits and don't hope to do well at solo projects when you are
in it for learning or bug hunting.

------
at_a_remove
I am all about the boring technology. I dislike the churn of learning
something only to discard that knowledge in favor of something else a few
months later. I would rather get better at the things I know how to do rather
than learn how to do something new and hope to get proficient at it. It feels
like time wasted, learning something that I know is disposable.

I get it, in the end everything is disposable but I like to minimize that
churn and polish what I have that works for me. It isn't as fashionable or as
cool but I try to avoid those circles if I can.

------
noncoml
I thought MongoDB and NodeJS _are_ the boring technology today...

Edit: Oh, it needs a (2015)

~~~
bob1029
I don't think 5 years has done much of a favor for MongoDB.

Boring in this context doesn't necessarily mean 'old' technology. It means
technology that is so stable & reliable that you forget it's there.

I can go weeks on end before being tangentially reminded that we use SQLite to
store business entities. I am usually in the arena of business logic working
with our various customers. This is what boring technology means to me. Stuff
that "just works" and never causes you to spend any time worrying about it.

------
tjpnz
This is something I've lived by for the majority of my career. I wish I could
share in the excitement of my peers when they discover a new shiny thing and
push really hard to have it incorporated, my inability to share in that
excitement has even shaken my confidence at times. What's worse is that it has
resulted in friction at some of the places I've worked, even more so when the
issues I've raised end up biting us hard in production.

------
systematical
The most recent MVP I created: CakePHP, MySQL, jQuery (UI/UX called for
minimal dynamic UI IMO), and bootstrap. Very boring full-scale MVP released in
under three weeks. I designed as client-server in case the need arises to go
SPA with React down the line or go with a mobile app option, but I doubt the
need.

Non-tech co-founder was worried from what he read on PHP etc.... Non-tech co-
founder is not worried today.

------
LukeEF
This thing is on a 6 month hacker news circuit. And front page every time.
There is a psychological conceit in the backend about using tech 'that has 20
years of maturity' \- that plays out with DBs more than anywhere else. 'Let
the others do the innovation' seems to be the desire.

------
smabie
If I use APL and Lisp, does that count as spending innovation tokens? Is
boring technology old, or is it widely used? Most people I know don't consider
J, kdb+/q, Haskell, or OCaml boring, but they are all awesome industrial
strength languages/technologies.

~~~
invalidOrTaken
Boring is boring---i.e., no surprises. Whether it's been tested by a lot of
other people, a lot of years, or even just a lot of _your_ time. APL is not
boring to me, but it might be to you.

------
hliyan
Rapid progress and multiple options (like we have with front-end libraries,
tool chains and cloud infrastructure) are great, if standardization (at least
of the interfaces and vocabulary, if not the implementations) comes in their
wake. Otherwise, only fragmentation, unpredictability and pain you will find.

Edit: Just an hour ago I was learning Heroku (having primarily worked with
AWS, Linode and bare-metal) and I found that they call a collection of Linux
containers a _dyno_. So we have _droplets_ (confession: never used these),
_pods_ , _clusters_ and now _dynos_. If nothing else, should we not at least
standardize the vocabulary?

~~~
jakelazaroff
“Droplets” as in DigitalOcean? Those are literally just single virtualized
servers — nothing fancy or property happening there, despite the cutesy name.

------
aaronbrethorst
Five years ago I posted a comment on this same article, which you can read at
[https://news.ycombinator.com/item?id=9291437](https://news.ycombinator.com/item?id=9291437)

I still stand by everything I said in that comment, and it has served me
incredibly well on every project I've worked on since. At least in the cases
where I followed my own advice :-\

tl;dr: if you're trying to build and ship something quickly, don't use any new
technology. If you want to use your project as an excuse to learn a new
technology, limit yourself to only one technology so you can better isolate
issues when they crop up.

------
rooam-dev
Boring tech is subjective, it depends on the team. A tool for the job needs to
be in right hands to be right. Some may be fine with 1 hour after hours
deployment, some may want a fully automated CD pipeline.

~~~
darkwater
Nope, boring technology implies mature and tried enough ecosystem where the
users community found out and know almost every failure scenario. Your team
skills are not relevant in this definition, if a tech is "new" and "exciting".

~~~
rooam-dev
Indeed, team's experience is not relevant in the definition, however it's the
main criteria to choose a [boring] tech, after the cost of course.

To use/apply any tech or workflow depends on execution.

------
markus_zhang
I actually get why engineers, especially young ones prefer new techs
sometimes.

Think it this way. You join a company and get two choices. One is to use a
reliable albeit old system, read tons of legacy code and figure out how to do
things other guys' way. The other is to build new things from ground up when
you have a much bigger feeling of ownership, but risk breaking things up.

Which one do you choose? Note that you are a junior engineer, not a lead, not
an architect.

Somewhat this is more like a class struggle instead of choosing the right
tech.

~~~
djmips
Every boring tech was once new and exciting at one time. Without someone
taking a risk everything would be boring.

~~~
markus_zhang
Yeah exactly.

------
aww_dang
I like to learn new things and solve new problems, but "Don't fix it if it
isn't broken" are words to live by. Challenging myself with a new problem is
rarely boring.

So many new technologies seem like something new just for the sake of it. By
the time they mature into something as practical as 'boring tech' they have
many of the same pitfalls if not more.

Perhaps many engineers lack agency in choosing the problems they solve, so
they seek to change the tools they use instead?

------
MattGaiser
This makes sense until I need to find a new job in 18 months.

~~~
jasonkester
The solution to this is to use the New Shiny at your day job, and the good
boring stuff for your own projects:

[https://expatsoftware.com/articles/happiness-is-a-boring-
sta...](https://expatsoftware.com/articles/happiness-is-a-boring-stack.html)

If it’s Somebody Else’s Money paying for the development, go nuts with
whatever crazy tech their 19 year old CTO wants to roll with. Hopefully they
have a VC holding the bag to subsidise the ride.

But when it’s your stuff, and it’s your weekends you’ll lose when it breaks,
use something solid to build it.

~~~
midrus
I was really hoping this was sarcasm, but sadly I've seen this happen far too
many times already.

There is some impunity going on where the people making these kind of
decisions in some companies when things fall down they just blame it on
something else and switch jobs, and now you're stuck with mongodb or a django
where somebody thought using sqlalchemy instead of the ORM was a good idea or
a monorepo with all company's frontend code and its 14Gb of source code for
scripts to make the tooling work in such monstrosity.

~~~
ProZsolt
When most of the companies expect you to hit the ground running with every
technology they use, I can't really blame them. If companies don't want to
train the employees when they start in a new position, they will train
themself when they about to leave.

------
dmnd
I'm constantly invoking this principle, but I have a small tweak: combine it
with the (now anachronistically named) Python Paradox to get "use a tool from
your toolbox".

Restricting the number of different technologies in your toolbox gets you most
of the benefits described in TFA. But contrary to "boring", it's actually
preferable for some of those tools to be bleeding edge. That way you also get
to enjoy the benefits of the Python Paradox.

Of course, you need to have good enough taste to pick new techs, and sometimes
the bleeding edge will cut you. But because you amortize that cut over the
whole org it doesn't hurt much.

~~~
brabel
> you need to have good enough taste to pick new techs...

So you see tech as you see fashion, i.e it requires good taste?!

When you choose a new tech, perhaps you should consider what problems it
solves and whether its costs are worthwhile for you, not whether its a hot new
fashionable thing to "wear" in parties (conferences).

~~~
dmnd
Tasteful ≠ trendy. By “good taste” I meant the ability to pick a technology
you won’t regret later.

------
ncmncm
It's funny that he mentions Rumsfeld, without mentioning Rumsfeld's very
public glaring omission that was ultimately responsible for everything that
went wrong in Iraq.

He cited "known knowns", "known unknowns", and "unknown unknowns", but
completely missed the biggie, unknown knowns -- things you are convinced are
true, but in fact are not.

"It ain't what you don't know that gets you. It's the things you think you
know that just aren't so." (Often mis-attributed to Mark Twain, but Josh
Billings is a better choice.)

------
ngngngng
I once overheard a conversation between two colleagues.

"I'm not interested in learning Go because it doesn't have many compelling
features"

"That IS the feature"

~~~
theshrike79
Having to build stuff from basic blocks with no hidden magic is the best part
in Go.

It's SO boring, but also very efficient. Yes, you type more words, but that's
why you got the fancy clicky keyboard.

You get stuff done and other people can actually understand your code, because
there are no hidden gotchas, everything is just as you typed it out. Even the
boring and repetitive if err != nil stuff just fades away, but you DO notice
if it's missing somewhere.

~~~
xtracto
In 1999 when I finished my Bsc in Software Eng I loved to do my own tools
instead of using stdlib or boost or other C libraries for the same reason.

Now I value my time more and I prefer to focus on programming what gives value
to the business I am building to.

~~~
theshrike79
Go isn't _that_ basic =)

There are less abstractions to hide the costly operations.

------
giza182
Another reason for one to have side projects. With those, one has virtually an
unlimited supply of innovation tokens to play with.

------
GavinHoltUK
There are many parallels here for the selection of medical drugs and implants.
Use treatments with a good evidence base, predictable outcomes and known
complications (preferably with known solutions).

Don't insist upon the latest new treatment, unless you fully accept the rôle
of guinea pig - for better or worse!

------
andersco
This article reinforces one of the most important lessons I’ve learned as a
developer - be careful, even suspicious of shiny new things - only after the
sheen has faded after extensive use and they no longer are the new coolness is
it usually safe to consider them for anything other than a toy project.

------
quickthrower2
5 years later, NodeJS i'm using on a side project. I am assuming this is zero
innovation tokens now!

------
raverbashing
Yeah, this motto works. Until the "boring technology" breaks in your face or
have a gotcha that everybody "forgets to mention" (which you might be able to
work around, with various degrees of cleanliness).

And I've seen it happen a couple of times.

~~~
quintushoratius
...and that's different from new, unproven technology how?

Unproven technology has all that in spades.

------
wp381640
Welcome to the enterprise tech world - it's funny how hard-learned lessons are
re-learned in startups the hard way.

~~~
aaronbrethorst
Welcome to being older. It’s funny how hard-learned lessons are relearned by
younger people the hard way.

~~~
Toine
Exception in thread "main" java.lang.StackOverflowError

------
Animats
The key point: _" But more importantly, their (old technology) failure modes
are well understood."_

------
loughnane
When in doubt, make it stout out of stuff you know about.

------
r0rshrk
Ironic that Node is one of the boring choices nowadays.

------
thesandi001
Choosing boring tech ensures fastest GTM.

------
barbs
(2015)

------
Throwaway8588
Except the most employable technology keeps changing every few years.

TypeScript and Go and Rust are the hot ones now and they were barely on the
radar a year ago.

Ofc I am inserting them into work projects as I need to learn them.

~~~
hilbertseries
Rust may be “hot” but there are far more Java jobs than Rust jobs and I highly
doubt that’s going to change anytime soon. And indeed Java developers have
been highly employed for quite some time.

~~~
jghn
Agreed. I personally love the "hot" tech, but anyone claiming there are more
jobs for those skills than the tried & trued is being disingenuous

~~~
MattGaiser
I think it depends on where you want to work. If you check out the YC job
boards, they want TypeScript, Go, and GraphQL.

~~~
didibus
I've found in general the places that use Java don't look for a Java
developer. Its like they just assume you can pick it up. You might see things
like knowledge of OOP, SQL, etc. on the job listing. For example, lots of
large companies like Google, Microsoft, Amazon, Twitter, Netflix, etc. have a
ton of Java, but their job descriptions don't really mention it.

On the other hand, if a place needs Typescript, or GO, they'll mention it.

~~~
randombytes6869
I think job descriptions are just marketing materials for developers at a lot
of places. Advertising your COBOL just gets you people that want to make more
COBOL.

Every job I take, whatever the oldest crappiest technology mentioned in the
footnotes is, ends up being 90% of my job.

------
dotemacs
The author even has this whole site, which is essentially a slide deck:
[http://boringtechnology.club/](http://boringtechnology.club/)

But even though he talks about "boring" tech, he did go on to have a startup,
Skyliner, which was written in Clojure and subsequently acquired by Mailchimp.

So I guess, you can't be using the borking stack all the time...

