Choose Boring Technology (2015) | Hacker News Reader

Choose Boring Technology (2015)

mcfunley.com

42 pointslord_sudo13 comments

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.

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.

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-...

nothing lately, which is a shame...

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

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.

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

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!"

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.

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).

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.

Also see: interesting boring technology

https://www.cat-bus.com/2018/01/far-from-boringmeet-the-most...

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

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.

Reply on news.ycombinator.com