4 ms·

Choose Boring Technology (2015)

42 points by lord_sudo 5y ago

siemin93 5y ago
You lost me at „cron is good enough”. Cron is not even remotely good enough on any project which becomes anything more than a simple POC. Maybe You also run production servers in gnu screens? Come on.
- sam_lowry_ 5y ago
  I actually do run production code in gnu screen for mundane but frequently updated things like spambot mitigation or performance monitoring.
chinabot 5y ago
Works for me, last time I changed programming language and framework was over 20 years ago, but remember like TFA says to pick technologies that will be actively supported in 20 years, eg C and SQL are not going anywhere for a very long time
jppope 5y ago
McFunley has had some amazing moments in his career. "Choose Boring Technology", "data driven products now" and of course the "Richard is a fucking idiot control" which made its rounds... https://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered/184673 https://stackoverflow.com/questions/184618/what-is-the-best-... nothing lately, which is a shame...
- pronoiac 5y ago
  Background on RichardIsAFuckingIdiotControl: https://mcfunley.com/from-the-annals-of-dubious-achievement https://mcfunley.com/from-the-annals-of-dubious-achievement
shroompasta 5y ago
I would replace 'Boring' with 'Tried and True'. I was going to question the cost of an 'innovation token' for MongoDb and NodeJS, but I realized just now that this article was written in 2015. For every greenfield project that I came to build, I always gave considerable thought to finally using GraphQL as opposed to REST, just for the hype and growth. Don't get me wrong, I understand the use-cases of GQL, especially in the context of multiple types of clients that don't obtain the same responses, but my appetite and longing to use GQL was always because the guy next door was using it and I didn't want to get left behind. Furthermore, it's not like I can't implement some form of 'data shaving' through query params or detecting mobile / pc through user agent, or just simply adding another endpoint (or a couple), which basically solves what GQL has to offer. That being said, I always went back to REST because it just worked - a request to and endpoint which hit the db, was simple, tried, and true. A lot of new technologies nowadays are solving problems that we didn't know we had, and a lot of it is due to hype with young engineers catching the wave simply because it's got a classy and fashionable looking landing page, when really the favorable solution is the tried and true tech. But hey, sometimes the wave does build, and sometimes, we do have to get on board or get left behind.
- BackBlast 5y ago
  I pick REST over GQL and such also. GQL has some distinct disadvantages that people seem to gloss over. Front end architecture seldom is oriented around making efficient queries. My last slot that used it as glorified REST and didn't shrink the number of queries to the backend. It does make more sense if you have a variety of consumers of the data, but meh, after my experience I still wouldn't use GQL. Higher complexity in the backend. Our GQL backend was schema stitched together microservices. Highly complex, random services would bring the whole thing down, and it was not understood why. The schema stitching happened on every request and seemed very "heavy and slow" to me. Not all of that was the fault of GQL, but, it definitely provided more room to mess things up. Caching nightmare. Heavier client library. And on and on. Grass is not greener IMHO.
ant6n 5y ago
Also see: interesting boring technology https://www.cat-bus.com/2018/01/far-from-boringmeet-the-most-interesting-tunnel-boring-machines/ https://www.cat-bus.com/2018/01/far-from-boringmeet-the-most...
LAC-Tech 5y ago
Funny how back in 2015 node.js was seen as some exciting unstable thing. In 2022 it's honestly the most practical choice for me - I'd like to play with other stuff but if I had to a put a backend together quickly I'd undoubtedly reach for node. (Though I realise I'm missing the forest for the trees here - your boring technology is not necessarily mine).
- aradaelli 5y ago
  Node js is definitely great to kickstart a new project. However I believe it becomes a trap when you start to pull in dependencies. I recently resurrected a node.js project, just 3 years old, expecting it to be working as the day as I archived it. Well no. A package broke because of the newer version of Node.js. Therefore I performed a full upgrade of all packages and then _my code_ broke because some other package did not maintain backwards compatibility. So I reverted everything back and manually upgraded only the necessary packages to make everything working again. Both NPM and Github tell me how many unsecured packages I am using but I don't care, it's a project I am using for myself. But if it was for work I would have to spend time fixing a lot of broken things. I think Node.js is not a boring. It is young and still growing.
bitwize 5y ago
I pitch this at work as "Lateral Thinking with Withered Technology", and explain that it's a phrased coined by former Nintendo engineer Gunpei Yokoi to describe how Nintendo consistently delivers unique and profitable gaming experiences: innovating by combining old, reliable technologies in new ways. Attaching a large and successful company's name to the principle helps it go over with corporate types. Think how much leverage has been gained for HTTP APIs simply by saying "Hey, Amazon does it!"
deleted 5y ago
[deleted]
sam_lowry_ 5y ago
Choose boring technology if you do not care about the quality of the workforce nor about the difficulty of filling open positions. Dull SpringBoot-Cloud-Netflix-Angular jobs are a hard sell, but businesses that invest in slightly fringe technologies like Closure, Rust, Go, Vue.js, have good candidates at below market prices. Hell, even Erlang shops are bombarded by high quality applicants. Even plain C positions are quickly filled.
karmakaze 5y ago
I prefer the concept of innovative tech points. You get a small number, say 2, where you get to try something off the beaten path if you believe that will provide a competitive edge.

42 points by lord_sudo 5y ago

You lost me at „cron is good enough”. Cron is not even remotely good enough on any project which becomes anything more than a simple POC. Maybe You also run production servers in gnu screens? Come on.

sam_lowry_ 5y ago
I actually do run production code in gnu screen for mundane but frequently updated things like spambot mitigation or performance monitoring.

chinabot 5y ago

Works for me, last time I changed programming language and framework was over 20 years ago, but remember like TFA says to pick technologies that will be actively supported in 20 years, eg C and SQL are not going anywhere for a very long time

jppope 5y ago

McFunley has had some amazing moments in his career. "Choose Boring Technology", "data driven products now" and of course the "Richard is a fucking idiot control" which made its rounds... https://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered/184673 https://stackoverflow.com/questions/184618/what-is-the-best-... nothing lately, which is a shame...

pronoiac 5y ago
Background on RichardIsAFuckingIdiotControl: https://mcfunley.com/from-the-annals-of-dubious-achievement https://mcfunley.com/from-the-annals-of-dubious-achievement

shroompasta 5y ago

I would replace 'Boring' with 'Tried and True'. I was going to question the cost of an 'innovation token' for MongoDb and NodeJS, but I realized just now that this article was written in 2015. For every greenfield project that I came to build, I always gave considerable thought to finally using GraphQL as opposed to REST, just for the hype and growth. Don't get me wrong, I understand the use-cases of GQL, especially in the context of multiple types of clients that don't obtain the same responses, but my appetite and longing to use GQL was always because the guy next door was using it and I didn't want to get left behind. Furthermore, it's not like I can't implement some form of 'data shaving' through query params or detecting mobile / pc through user agent, or just simply adding another endpoint (or a couple), which basically solves what GQL has to offer. That being said, I always went back to REST because it just worked - a request to and endpoint which hit the db, was simple, tried, and true. A lot of new technologies nowadays are solving problems that we didn't know we had, and a lot of it is due to hype with young engineers catching the wave simply because it's got a classy and fashionable looking landing page, when really the favorable solution is the tried and true tech. But hey, sometimes the wave does build, and sometimes, we do have to get on board or get left behind.

BackBlast 5y ago
I pick REST over GQL and such also. GQL has some distinct disadvantages that people seem to gloss over. Front end architecture seldom is oriented around making efficient queries. My last slot that used it as glorified REST and didn't shrink the number of queries to the backend. It does make more sense if you have a variety of consumers of the data, but meh, after my experience I still wouldn't use GQL. Higher complexity in the backend. Our GQL backend was schema stitched together microservices. Highly complex, random services would bring the whole thing down, and it was not understood why. The schema stitching happened on every request and seemed very "heavy and slow" to me. Not all of that was the fault of GQL, but, it definitely provided more room to mess things up. Caching nightmare. Heavier client library. And on and on. Grass is not greener IMHO.

ant6n 5y ago

Also see: interesting boring technology https://www.cat-bus.com/2018/01/far-from-boringmeet-the-most-interesting-tunnel-boring-machines/ https://www.cat-bus.com/2018/01/far-from-boringmeet-the-most...

LAC-Tech 5y ago

Funny how back in 2015 node.js was seen as some exciting unstable thing. In 2022 it's honestly the most practical choice for me - I'd like to play with other stuff but if I had to a put a backend together quickly I'd undoubtedly reach for node. (Though I realise I'm missing the forest for the trees here - your boring technology is not necessarily mine).

aradaelli 5y ago
Node js is definitely great to kickstart a new project. However I believe it becomes a trap when you start to pull in dependencies. I recently resurrected a node.js project, just 3 years old, expecting it to be working as the day as I archived it. Well no. A package broke because of the newer version of Node.js. Therefore I performed a full upgrade of all packages and then _my code_ broke because some other package did not maintain backwards compatibility. So I reverted everything back and manually upgraded only the necessary packages to make everything working again. Both NPM and Github tell me how many unsecured packages I am using but I don't care, it's a project I am using for myself. But if it was for work I would have to spend time fixing a lot of broken things. I think Node.js is not a boring. It is young and still growing.

bitwize 5y ago

I pitch this at work as "Lateral Thinking with Withered Technology", and explain that it's a phrased coined by former Nintendo engineer Gunpei Yokoi to describe how Nintendo consistently delivers unique and profitable gaming experiences: innovating by combining old, reliable technologies in new ways. Attaching a large and successful company's name to the principle helps it go over with corporate types. Think how much leverage has been gained for HTTP APIs simply by saying "Hey, Amazon does it!"

deleted 5y ago

[deleted]

sam_lowry_ 5y ago

Choose boring technology if you do not care about the quality of the workforce nor about the difficulty of filling open positions. Dull SpringBoot-Cloud-Netflix-Angular jobs are a hard sell, but businesses that invest in slightly fringe technologies like Closure, Rust, Go, Vue.js, have good candidates at below market prices. Hell, even Erlang shops are bombarded by high quality applicants. Even plain C positions are quickly filled.

karmakaze 5y ago

I prefer the concept of innovative tech points. You get a small number, say 2, where you get to try something off the beaten path if you believe that will provide a competitive edge.