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

Choose Boring Technology (2015)

mcfunley.com

Post reply on HN
Print view View original

51–60 of 269 posts

Re: Choose Boring Technology (2015)

#51

Post by insanitybit »

simonw wrote: post #43
insanitybit wrote: post #19

I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and feels sort of unserious. Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. For example, I may thin…

> What if you know NodeJS really well? Or MongoDb? Then they're not boring. Boring isn't a universal trait, it has to be evaluated within the context of your own team.

Then it's useless. If I have to take the context into account then I should be prepared to have a conversation about the requirements and how the technology fits it, which "boring" does not facilitate (and discourages).

Re: Choose Boring Technology (2015)

#52

Post by krapht »

PyWoody wrote: post #12
nomel wrote: post #7

Earlier quoted context omitted.

There was another, much older, post similar to this about, I think, "beans" that engineers use to solve problems. If I remember correctly, it was something like, solving a problem costs "beans", and engineers will always use most all of their "beans" to solve a given problem, because it's somewhat "easy" until you run out of them. Maybe it wasn't beans? But, I've been looking for it for years.

Not what you're after, but your talk of beans reminded me of Taco Bell Programming. [0] [0] https://widgetsandshit.com/teddziuba/2010/10/taco-bell-progr...

His example of a web crawler stinks. I can get behind the philosophy, but his specific web crawler example at a minimum needs to retry, respect robots.txt, and rate limit per domain. So no, xargs + curl is a dumb example.

Re: Choose Boring Technology (2015)

#53

Post by dwedge »

simonw wrote: post #46
dwedge wrote: post #31

I read a similar blog post years ago about restricting the technologies you use, and making do with a slightly worse option if it means reusing the stack you already have. The example they gave was something like they wanted to use rabbitmq for a new side project (I might be misremembering) but they were forced to make it work with redis instead. The author said that years later he found out that that side project ha…

Pretty sure it was this one linked in the OP. See this footnote: https://mcfunley.com/choose-boring-technology#f4 > A good example of this from my experience is Etsy’s activity feeds. When we built this feature, we were working pretty hard to consolidate most of Etsy onto PHP, MySQL, Memcached, and Gearman (a PHP job server). It was much more complicated to implement the feature on that stack than it might have been…

I can't believe I was asking about the same article. The flow of time made it feel different and I forgot this was one of my all time favourites that I've been trying to re-find for years. Thank you

Re: Choose Boring Technology (2015)

#54

Post by simonw »

insanitybit wrote: post #51
simonw wrote: post #43

Earlier quoted context omitted.

> What if you know NodeJS really well? Or MongoDb? Then they're not boring. Boring isn't a universal trait, it has to be evaluated within the context of your own team.

Then it's useless. If I have to take the context into account then I should be prepared to have a conversation about the requirements and how the technology fits it, which "boring" does not facilitate (and discourages).

Weird take. It's clearly useful as a communication tool. You talk to your team, you say "Let's use boring technology. Read the essay, then we can discuss what boring technology means to us first."

Re: Choose Boring Technology (2015)

#55

Post by Animats »

Some of this may have been a reaction to the era of Javascript framework churn. There were way too many different technologies for doing roughly the same job. They all more or less worked.

On the other hand, IBM was late getting into integrated circuits. They had Solid Logic Technology, automated machinery for putting transistors into ceramic substrates to make tiny but discrete circuits. That's what powered the IBM System/360. Worked, but kept mainframe prices high and made IBM late to minicomputers.

Innovation when the problem is hard is more interesting. Look at the history of US long range bombers. The B-29 was effective, but underpowered, and had a lot of trouble getting off the ground fully loaded. So, after WWII, the next development was the B-36, which answered the question "what if we scaled up the B-29?"[1] Six propellers, and four jet engines (added late in the design cycle). Was a sky barge, but it worked, as long as no one was trying hard to shoot it down. No flyable aircraft remain. That was the boring technology approach.

After that came the B-47, which answered the question "what if we scaled up a jet fighter to bomber size?"[2] The B-47 was all jets, no props. It needed solid-fuel rocket boosters (!) to help it get off the ground, and a drag chute to slow it down on landing. It was terrible to fly; its operating speed and altitude were too near the "coffin corner" where stall and Mach buffet meet.[3] No flyable aircraft remain.

Then came the B-52. New engines. New airframe. New design. [4] That's the high-risk approach. It worked. Hundreds are still in active service. Outlasted most of its successors, the B-58 Hustler (a supersonic intercontinental bomber), the B-70, the F-111, etc.

On the commercial side, we have Boeing, whose most successful airliner is a variant of the B-737, which first flew in 1967. But that's another story.

[1] https://www.youtube.com/watch?v=vKQYG_fA2uM

[2] https://www.youtube.com/watch?v=l1-urTRxeEM

[3] https://en.wikipedia.org/wiki/Coffin_corner_%28aerodynamics%...

[4] https://www.youtube.com/watch?v=k8EURBL53_k

Re: Choose Boring Technology (2015)

#56

Post by insanitybit »

simonw wrote: post #54
insanitybit wrote: post #51

Earlier quoted context omitted.

Then it's useless. If I have to take the context into account then I should be prepared to have a conversation about the requirements and how the technology fits it, which "boring" does not facilitate (and discourages).

Weird take. It's clearly useful as a communication tool. You talk to your team, you say "Let's use boring technology. Read the essay, then we can discuss what boring technology means to us first."

I obviously don't agree that it's useful as a communication tool though. Why not "Use the technology that's appropriate for our use case"? That seems radically better and doesn't suffer from weird misinterpretations or vague terms.

Re: Choose Boring Technology (2015)

#57

Post by insanitybit »

marcosdumay wrote: post #49
insanitybit wrote: post #19

I'll push back against this, despite it being so popular. I dislike the arbitrary "innovation tokens" and I think this entire concept really blurs the lines and feels sort of unserious. Engineers should understand requirements, risks, tradeoffs, and potential gains. New technology may be right for that. Novel approaches may be right for that. "Novel" or "New" are only proxies and they're weak. For example, I may thin…

> For example, I may think "New" means untested, but is that true? The article answers this, and the answer is "no". New technology is one you don't know the details of. > determine candidate solutions, and choose them based on their fit That's quite hard to do for solutions that you don't know the details. You have an objection to something. It's clearly not to the article's point, though.

> That's quite hard to do for solutions that you don't know the details.

That's a great thing to discuss when deciding on the technology. Maybe you should aim for solutions that you know well, or a solution that makes migrating away easy, or maybe you need to do some discovery work, etc.

> You have an objection to something. It's clearly not to the article's point, though.

It's an objection to the nature of the article itself - that technical decisions should work this way, that metaphors like "innovation tokens" are useful, that "boring" is a good proxy word.

Re: Choose Boring Technology (2015)

#58

Post by simonw »

insanitybit wrote: post #56
simonw wrote: post #54

Earlier quoted context omitted.

Weird take. It's clearly useful as a communication tool. You talk to your team, you say "Let's use boring technology. Read the essay, then we can discuss what boring technology means to us first."

I obviously don't agree that it's useful as a communication tool though. Why not "Use the technology that's appropriate for our use case"? That seems radically better and doesn't suffer from weird misinterpretations or vague terms.

Because people LOVE COMING UP with excuses to try a new technology under the basis that "this is appropriate for our use-case", and if you don't introduce a concept similar to innovation tokens you may find that six months later your project is combining three different unproven new technologies and doesn't actually work yet.

Encouraging your team to be selective in where they place their new bets - and use "boring" aka already-understood technology for the bits that are not going to help solve unique problems - can help avoid expensive mistakes.

Post reply on HN