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

121–130 of 356 posts

Re: Choose Boring Technology

#121

Post by lvh »

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 think the real punchline there is just "hiring is hard", because elsewhere in the comments someone has made the argument that you shouldn't use shiny technology because it's too hard to find people (specifically, you'd be screwed if that one person left). Maybe that's a company maturity thing: fancy tech is good for attracting talent early, boring tech is good for attracting a sufficiently large ops team later.

Re: Choose Boring Technology

#122

Post by chucky_z »

parasubvert wrote: post #98

A huge part of our VC bubble in OSS infrastructure (NoSQL, clouds, middleware, automation) is fueled by a generation of technologists not choosing boring technology. This is a great presentation, and great advice. What this piece misses are the marketing, hiring practices and incentives in that capital pool that is fueling FOMO (fear of missing out) as the main driver of our technology trends. Most people orbiting IT…

I would like to throw my 2 cents in that some of these advances around "new" ways do lead to some good things. The focus on service discovery is something that is incredibly helpful even for older technologies.

Consul is something you can add to even a very old application and give it modern scaling features, simply because it has a plain old DNS interface.

Redis is similar for caching, it's advanced, the interface is so simple to use, and it's so easy to deploy and manage.

On the flip side, I'd like to add that I worked for a startup and we chose a lot of boring technologies because we had a job to get done, and they all just worked. :)

Re: Choose Boring Technology

#123

Post by zzzcpan »

> 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 failure modes of "boring technology" in software and get perfectly working systems. But we can't, all the unknown unknowns and not understood failure modes are still there in boring technology, and reliability is a "do backups" afterthought. Systems really have to be designed for reliability if reliability is important and currently software reliability is too cutting edge to be boring.

Re: Choose Boring Technology

#124

Post by lvh »

fnord77 wrote: post #114
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…

See that slide that shows the bipartite graph of Problems on the left and Technology on the right. Typescript would be an extra edge in that graph and thus would impact the equation in the subsequent slides. So it would be a shiny new technology.

Can you elaborate? I don't quite understand.

(I also think TypeScript is a great example of a category breaker here since it's a lot closer to a linter than a database. Sure, you have a new compiler stage so it's not quite free :-))

Re: Choose Boring Technology

#125

Post by sudhirj »

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…

I’d say talk about it with the team, see there’s enough buy in from the existing team and enough awareness of the extra stuff to learn for both current and future team members. Then try it incrementally on some of the most hairy or type bug ridden parts of the codebase (so you can quickly prove utility) or on some smaller / newer parts of the code (so you can quickly prove compatibility). Then a wider rollout should build up its own momentum if it’s anywhere as helpful as you’re hoping it’s going to be.

Re: Choose Boring Technology

#126

Post by shapiro92 »

xwdv wrote: post #86

There’s a certain amount of ladder kicking involved in telling people to choose boring and beige technologies after you started up your career chasing after new and exciting shiny things. Every developer should spend some time working at the bleeding edge, so they know how it feels to get cut. The best time is absolutely at the beginning, when you’re a fresh grad and have the energy. You have the rest of your life to…

So much this! I mean the author also worked for 7 years at Etsy which did ship quite a lot of new things (bad and good). For me this is similar to telling a 20 year old, dont go out, stay home, watch tv you will less likely get injured.

Re: Choose Boring Technology

#127

Post by wlesieutre »

pif wrote: post #79
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…

> "Happiness comes from shipping stuff" Actually, the rest of your comments points to: "Happiness comes from shipping good stuff"

Maybe more that if you ship bad stuff you don't get to keep shipping stuff, you have to stop and worry about keeping the bad stuff running.

Be happy by shipping stuff, and keep shipping stuff by shipping good stuff.

Re: Choose Boring Technology

#128

Post by zzzcpan »

jerf wrote: post #91
lvh wrote: post #69

Author mentions Clojure a few times as an example of shiny-thing. Ironically, it's one of the few languages that I can reliably do in the browser, on the backend (on real servers or say, Lambdas), and build native binaries for -- which addresses the later "many tools" problem better than a "boring" programming language like Ruby. Unless you don't care about frontend code I guess :-) (Overall this talk is fine! I thin…

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.

Re: Choose Boring Technology

#130

Post by DougBTX »

malvosenior wrote: post #76
DougBTX wrote: post #62

Earlier quoted context omitted.

> fundamental features of the language The thing is you’re right, Go compiling to a self-contained binary is different from a folder of .py scripts. But both can be deployed into production. The deployment steps are different but the outcome is the same, so they can be used interchangeably.

If you use third party Python libraries, the end user is going to have to install them too. Python really isn't a great language to be building consumer distributed command line apps in. I think a lot of this discussion is focused around custom software or backend software, but for a publicly distributed binary, Go or any other compiled language is much better than Ruby or Python (and especially Javascript).

That isn't quite true re Python, eg https://stackoverflow.com/questions/2933/how-can-i-create-a-...

Go might be a special case actually, as it was designed to be a "boring" language to reduce the cost of technology choice. But it is completely interchangeable with similar programming languages (like Python) so evaluating the cost of it vs something else is still a very reasonable thing to do.

Post reply on HN