Choose Boring Technology (2015) • Hacker News Board

Re: Choose Boring Technology (2015)

#11

Post by Mikushi » Sun, Feb 21, 2021, 9:29 AM UTC

phendrenad2 wrote: post #2

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

> The last line of defense against a rogue engineering team is managers who have studied this stuff.

If your engineering team is the one pushing in that direction I'd reckon the company was in a bad spot to begin with to have hired that team because it strongly indicates that the management layer (head of tech/CTO) has no technical clue.

Hire strong Lead Developers with a proven track record of delivering value to companies they worked at and you'll be mostly fine.

Also there's not much to study, in 99% of the cases in a web based startup if your stack deviates from a monolith with one of PHP/Ruby/Python/.NET/Go + Mysql/Postgres/MSSQL you're doing it wrong.

Re: Choose Boring Technology (2015)

#12

Post by arkitaip » Sun, Feb 21, 2021, 9:32 AM UTC

trestenhortz wrote: post #3

Generalizations like “choose boring technology” are just unhelpful slogans. Truth is you should choose technology given consideration of its pros and cons, not on the basis of some slogan. There are very good reasons to use mature technologies and very good reasons to use current technologies and very good reasons to use absolute cutting edge technologies. When someone comes at your approach wielding a slogan, be ske…

The author even addresses your criticism, i.e. how the title of the talk makes people focus on the wrong detail level of his thesis...

Re: Choose Boring Technology (2015)

#13

Post by code_duck » Sun, Feb 21, 2021, 9:42 AM UTC

phendrenad2 wrote: post #2

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

I had a small business depending on the Etsy API during the time they transitioned some storage to Mongo. The immediate effect for us was a downturn in functionality and reliability with no apparent advantages. In the midst of other serious concerns about their direction, we questioned why Etsy was doing this on the API mailing list and were told basically we didn't know what we were talking about and it wasn't out business. Fair enough, sort of.

It was a hot time for NoSQL and document DBs. Having investigated using Mongo myself to little avail, I asked why they didn't just use Postgres. If I recall correctly, a couple years later they published a Mongo at Etsy postmortem which concluded they should have just stayed with Postgres.

Re: Choose Boring Technology (2015)

#14

Post by krenel » Sun, Feb 21, 2021, 9:42 AM UTC

trestenhortz wrote: post #10

krenel wrote: post #8

Earlier quoted context omitted.

> When someone comes at your approach wielding a slogan, be skeptical. I do agree. Although the point of the article is to _lean_ more on "boring technology" side of, and paying extra effort when considering adopting newest flashy things. Having read the article 3-4 time in the last years, I don't think they say "don't use new things", just "not too many new things at the same time"

Perhaps the title should be “err on the side of boring technologies”, although I don’t even agree with that. The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors. Your project may really need to use all beta release software, cause maybe it just does.

I would agree that we're talking about the same thing, really:

> The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors

It's _usually_ difficult to take into consideration all the factors of a new flashy thing. The unknown unknowns. Thus _maybe_ choosing a trendy set of technologies might indicate that the exercise of balance and consideration you were commenting and that I do agree with 100%, has not been as honest as possible.

Re: Choose Boring Technology (2015)

#15

Post by the_gipsy » Sun, Feb 21, 2021, 9:43 AM UTC

nicois wrote: post #9

The redis/memcache example doesn't make a lot of sense to me, unless the idea is that a separate memcache instance is deployed alongside each backend, while redis would have been a single instance. I'm all for boring technology; reimplementing web protocols and semantics in JS is a disaster - and would probably have made a clearer case study than comparing to memory-first database caches.

Especially when he said that some people did have to work on that setup to scale it up. Sounds like devops work, so the same would have happened with redis, right?

Re: Choose Boring Technology (2015)

#16

Post by sverhagen » Sun, Feb 21, 2021, 9:46 AM UTC

trestenhortz wrote: post #10

krenel wrote: post #8

Earlier quoted context omitted.

> When someone comes at your approach wielding a slogan, be skeptical. I do agree. Although the point of the article is to _lean_ more on "boring technology" side of, and paying extra effort when considering adopting newest flashy things. Having read the article 3-4 time in the last years, I don't think they say "don't use new things", just "not too many new things at the same time"

Perhaps the title should be “err on the side of boring technologies”, although I don’t even agree with that. The right technologies for a project are the ones you deem to be right, given appropriate consideration of many factors. Your project may really need to use all beta release software, cause maybe it just does.

It may. But probably it doesn't.

Let's say you've given it the proper consideration, and it's clear beyond the smell of subjectivity that it needs to be flashy stuff, go for it. The point is that this is often not the case, and the argument is to go with boring then.

Re: Choose Boring Technology (2015)

#17

Post by the_gipsy » Sun, Feb 21, 2021, 9:48 AM UTC

I think there's an unfairness angle to it, if someone like the CTO makes the "boring" call. He then hacks maybe a few things here and there, but the one's to "sucker up" are the devs who have to program some "boring" shitty tech every day.

Re: Choose Boring Technology (2015)

#18

Post by wrnr » Sun, Feb 21, 2021, 9:52 AM UTC

This stack can be radically simplified:

Apache: managing open connections. Memcache: holding stuff in memory. Postgresql: Save stuff to disk. Cron: Schedule things. Python: wire the above things together

... or a good reason the pick Go or Java

Re: Choose Boring Technology (2015)

#19

Post by galfarragem » Sun, Feb 21, 2021, 9:52 AM UTC

krenel wrote: post #8

trestenhortz wrote: post #3

Generalizations like “choose boring technology” are just unhelpful slogans. Truth is you should choose technology given consideration of its pros and cons, not on the basis of some slogan. There are very good reasons to use mature technologies and very good reasons to use current technologies and very good reasons to use absolute cutting edge technologies. When someone comes at your approach wielding a slogan, be ske…

> When someone comes at your approach wielding a slogan, be skeptical. I do agree. Although the point of the article is to _lean_ more on "boring technology" side of, and paying extra effort when considering adopting newest flashy things. Having read the article 3-4 time in the last years, I don't think they say "don't use new things", just "not too many new things at the same time"

It could be rephrased as: spend your "innovation tokens" wisely.

Re: Choose Boring Technology (2015)

#20

Post by ramraj07 » Sun, Feb 21, 2021, 9:53 AM UTC

trestenhortz wrote: post #3

Generalizations like “choose boring technology” are just unhelpful slogans. Truth is you should choose technology given consideration of its pros and cons, not on the basis of some slogan. There are very good reasons to use mature technologies and very good reasons to use current technologies and very good reasons to use absolute cutting edge technologies. When someone comes at your approach wielding a slogan, be ske…

One reason to use non-boring new technology is if it suddenly enables abilities that were previously not possible.

The trap most engineers fail is that they only think about scaling. It's obviously an interesting problem, but until a company becomes successful it's not really something you should worry about, and for the most part things that (allegedly) scale well are more expensive, slower and harder to maintain.

But there are so many ways to innovate that's not just about scaling: can you make your application faster? What are things you never even considered because you have subconsciously internalised as a physical limit of reality when actually it's not?

One of the examples I'm currently exploring is the idea of moving a large amount of data in memory. I remember decades back when Google announced that it's search indexes are now fully in memory (they proudly announced that any given search query might run through a thousand computers). I cannot imagine how many possibilities it enabled for their product that were not possible before. The experimentation with new technology in pursuit of completely new ways of exploring your problem space should always be encouraged, and if boring technology cannot do it then that's when you give up on it.