Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology

boringtechnology.club

Post reply on HN
Print view View original

131–140 of 356 posts

Re: Choose Boring Technology

#131

Post by nixpulvis »

zzzcpan wrote: post #123

> The failure modes of boring technology are well-understood Well-understood failure modes can't get you to resilience and are not all that well-understood to begin with. I guess it's just a false justification people use to stick to familiar broken old technology and broken ways or maybe to avoid relying on people with rare expertise, I don't know. If things were as simple as this we would just handle all the failur…

Depends what you mean... it is often easy to wrap fallible dependency calls with exception logic, and even workarounds sometimes, as long as the logic and failure are clear.

It's mostly a matter of choosing boring software, because it's well documented, both in terms of (semi)-official docs, and things like SO answers, vs. newer software that might have modern advantages and also more undocumented or untested edge cases to be fixed.

Re: Choose Boring Technology

#132

Post by jerf »

zzzcpan wrote: post #128
jerf wrote: post #91

Earlier quoted context omitted.

Generally, "shiny-things" have some sort of appeal over the "boring" technology, or nobody would choose them at all. One of the places I'd say they are appropriate are in places where you have some problem where some "shiny-thing" stands head and shoulders above the "boring technology" in some particular and you can ram home those advantages well enough to overcome the other issues. For instance, if you've got a serv…

> I'm still recovering from some old "NoSQL" decisions made in a context where a relational database would have been more than adequate People jumped to NoSQL because of how awful a relational database actually is to operate. I guess it's easy to forget.

True, but in this context, they had a relational database, and the relational database is still there, and isn't going anywhere, so not a big win there.

Plus, the real problem is that the correct solution was something that was already boring at the time, memcached. If all you literally are using a "NoSQL" database like MongoDB for is a key-value store and literally nothing else, you don't need NoSQL, you just need a boring key-value store.

Re: Choose Boring Technology

#133

Post by pjmlp »

diroussel wrote: post #50
amelius wrote: post #18

Earlier quoted context omitted.

There's even an expression for it: reinventing the wheel.

The funny thing about that expression is that wheels have never been reinvented. As far as we know. The Summarians had them, and the technology spread through contract with other civilizations. But not as far as we know re-invented anywhere else.

I think people at the same epoch living in other continents did reinvent them.

Re: Choose Boring Technology

#134

Post by Datenstrom »

oftenwrong wrote: post #58

Always glad to see this making the rounds, as it has been influential for me, especially the perspective of "Happiness comes from shipping stuff". I often think about this part, in particular: >Then we walked away. We didn’t do anything related to activity feeds for years after that. We barely even thought about it. >Then one day I said, “hey, I wonder how activity feeds is doing.” And I looked at it and was surprise…

Beautiful code denies its existence so perfectly you forget you wrote it.

Re: Choose Boring Technology

#135

Post by steve_adams_86 »

sethc2 wrote: post #107

If you work on a Node backend with Javascript, Where does the idea of switching to Typescript fall into this discussion? Is it a boring technology, or a shiny new technology? It is still using the same tech in Node, which you already know the benefits and pitfalls for, but it isn't like there is no overhead to start consuming Typescript if you haven't used it before. My hope is for those who agree with the author's p…

A wonderful thing about TypeScript is that if you decide you don't like it or need it, you still have recognizable and refactorable JavaScript. On the other hand, if you have a ton of relational data and get excited about the latest nosql DB, you're going to have a hell of a time unravelling that mess.

Re: Choose Boring Technology

#136

Post by JustSomeNobody »

zzzcpan wrote: post #123

> The failure modes of boring technology are well-understood Well-understood failure modes can't get you to resilience and are not all that well-understood to begin with. I guess it's just a false justification people use to stick to familiar broken old technology and broken ways or maybe to avoid relying on people with rare expertise, I don't know. If things were as simple as this we would just handle all the failur…

> I guess it's just a false justification people use to stick to familiar broken old technology and broken ways or maybe to avoid relying on people with rare expertise, I don't know.

This sounds a bit nose in the air to me.

> Systems really have to be designed for reliability if reliability is important and currently software reliability is too cutting edge to be boring.

And yet, people have posted examples of "boring" software running for over a decade.

Re: Choose Boring Technology

#137

Post by chasd00 »

merb wrote: post #85
jasode wrote: post #17

As a meta observation, I noticed this was submitted by user luu and his website also has a blog post with a similar theme ("boring languages"[1]). Therefore, I wonder if the "boring vs exciting" advice somewhat depends on the personality. I.e. if person has a tendency to prefer conservative technology, it means external advice that advocates "boring tech" will resonate with that person. I think choosing boring techno…

> From what I read, Google's first AdWords server in 2000 was built on MySQL. MySQL was released in 1995 so using a relatively new 5-year old technology may have been more risky than picking traditional Oracle RDBMS which had been around since the late 1970s. well they could've also used postgres/ingress. but at the time it was way less used than mysql and way more conservative. mysql was probably used because in the…

i remember mysql being all the rage when it came out because it was "fast". I don't remember what it was compared to but the reputation was a fast database. I remember the postgres crowd bemoaning mysql's lack of ACID compliance (this was even before innodb came out) and the response was "yeah but it's fast".

Re: Choose Boring Technology

#138

Post by JustSomeNobody »

fnord77 wrote: post #118

This is great and I agree 100%. The problem we faced is hiring people. We found that in order to attract talent, we had to let them use the shiny new technology. Otherwise it would be hard to attract anyone.

I can see that. It's a shame though. Personally, I prefer to work on interesting projects. The tech stack used is an afterthought for me.

Re: Choose Boring Technology

#139

Post by KaiserPro »

sethc2 wrote: post #107

If you work on a Node backend with Javascript, Where does the idea of switching to Typescript fall into this discussion? Is it a boring technology, or a shiny new technology? It is still using the same tech in Node, which you already know the benefits and pitfalls for, but it isn't like there is no overhead to start consuming Typescript if you haven't used it before. My hope is for those who agree with the author's p…

It fits in the ruby part here: http://boringtechnology.club/#33

It would be something that you are adding to the stack. Yes, you are intending to replace something, but in practice there will still be legacy nodejs hanging around.

But crucially this one: http://boringtechnology.club/#43

If you are spending time (and therefore money) changing from one language to another, you are not making features for the business. Yes, you might get more speed re-implementing features, but its almost never going to make up for the hit you took in porting everything.

Re: Choose Boring Technology

#140

Post by pjmlp »

jacques_chester wrote: post #35
murgindrag wrote: post #23

Earlier quoted context omitted.

I'll contradict everyone here: You figure it out on a case-by-case basis. Generally, risks go down over time and with broad use. SQL, as a technology, is 100% risk-free, having been around forever, and widely used. COBOL is high risk, since while it's been around forever, hardly anyone uses it anymore, at least on modern projects. Moving your Cobol app to Android is fraught with unknown-unknown risk. Something that's…

Oracle created a brand new market in Java support contracts which didn't exist before, so that they could enter it and make a buck (wherein FUD is a standard sales tactic for them). They probably viewed their position on the OpenJDK as subsidising a public good, which in general is slightly out of character for Oracle. Most enterprise vendors have, or will soon have, comparable products for sale. My employers have Pi…

Sun also used to sell Java support contracts.

By the time they went under, Java 1.2 up to Java 5 were only available under support contracts for production deployment.

Somehow Oracle hate ends up excusing Sun for exactly the same practices.

Post reply on HN