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

41–50 of 269 posts

Re: Choose Boring Technology (2015)

#41

Post by insanitybit »

geodel wrote: post #39
insanitybit wrote: post #27

Earlier quoted context omitted.

So then say that.

Well its understood. Maybe your definition of explicitness is only met by things written like Principia Mathematica.

If it's understood then it's pointless. I also reject that it's understood.

I have no idea why you're talking about Prinicipia Mathematica as if I'm advocating for some sort of formal verification or extraordinary rigor as opposed to my suggestion that people just use their words and have reasons behind their decisions.

Re: Choose Boring Technology (2015)

#42

Post by simonw »

conrs wrote: post #8

Love this post. Surprisingly controversial; it hasn't made me very many engineering friends.

Yeah, it's pretty unpopular among people who like to try out new technology on every given project.

I've found it extremely useful over the years, personally.

Re: Choose Boring Technology (2015)

#43

Post by simonw »

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.

Re: Choose Boring Technology (2015)

#44

Post by geodel »

insanitybit wrote: post #35
geodel wrote: post #30

Earlier quoted context omitted.

Well your points are making sense in isolation whereas this article is making more sense in general. > I'm a bit tired of "simple" and "boring" and other nonsense words in this field... This is hilarious in sense millions more will be tired and exhausted by evaluating new and exciting technology endlessly appearing all the time. People go by these rule of thumbs which may not be perfect in every single case but they…

I don't think it's exhausting to determine if a solution fits your requirements and I don't think much about the people who would find it exhausting. I'm not suggesting some insane formal verification, but you really can't just answer basic questions about how technologies can address problems? Then what is your role? To choose mysql irrespective of requirements? > People go by these rule of thumbs which may not be p…

Well mysql likely will turnout to be better choice than choosing "Cloud scale nosql DBs" when evaluators have rather limited hands-on knowledge about either of them.

Re: Choose Boring Technology (2015)

#45

Post by i_like_robots »

insanitybit wrote: post #33
i_like_robots wrote: post #29

Earlier quoted context omitted.

I see innovation as a guardrail against CV driven development. More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution - I remember more than a handful of projects failing (either undelivered or rewritten well under their expected lifecycle) around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn'…

CV driven development is just as well guarded against by asking someone to justify their technical decisions based on the requirements and how the solution meets them. So "boring" does nothing to further that. > More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution It's linked today, people feel it's relevant today. This isn't a historic piece about how…

You seem to agree with the lecture/article but disagree with the title.

However, it's influenced a lot of people for more than a decade and the snippy title might well have something to do with that.

Re: Choose Boring Technology (2015)

#46

Post by simonw »

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 with something like Redis (or maybe not). But it is absolutely possible to build activity feeds on that stack.

> An amazing thing happened with that project: our attention turned elsewhere for several years. During that time, activity feeds scaled up 20x while nobody was watching it at all. We made no changes whatsoever specifically targeted at activity feeds, but everything worked out fine as usage exploded because we were using a shared platform. This is the long-term benefit of restraint in technology choices in a nutshell.

Re: Choose Boring Technology (2015)

#48

Post by insanitybit »

i_like_robots wrote: post #45
insanitybit wrote: post #33

Earlier quoted context omitted.

CV driven development is just as well guarded against by asking someone to justify their technical decisions based on the requirements and how the solution meets them. So "boring" does nothing to further that. > More, I think you need to consider the context of when this was written. It was a period of rapid innovation/evolution It's linked today, people feel it's relevant today. This isn't a historic piece about how…

You seem to agree with the lecture/article but disagree with the title. However, it's influenced a lot of people for more than a decade and the snippy title might well have something to do with that.

I don't agree with the article though and I dislike the influence it has had. I have seen engineers use "Boring" to justify "I know this technology" for situations where that technology is a bad fit.

Conversations about technical solutions are bespoke, there is no one term that can or should be used to guide them.

Re: Choose Boring Technology (2015)

#49

Post by marcosdumay »

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.

Re: Choose Boring Technology (2015)

#50

Post by insanitybit »

geodel wrote: post #44
insanitybit wrote: post #35

Earlier quoted context omitted.

I don't think it's exhausting to determine if a solution fits your requirements and I don't think much about the people who would find it exhausting. I'm not suggesting some insane formal verification, but you really can't just answer basic questions about how technologies can address problems? Then what is your role? To choose mysql irrespective of requirements? > People go by these rule of thumbs which may not be p…

Well mysql likely will turnout to be better choice than choosing "Cloud scale nosql DBs" when evaluators have rather limited hands-on knowledge about either of them.

> Well mysql likely will turnout to be better choice than choosing "Cloud scale nosql DBs" when evaluators have rather limited hands-on knowledge about either of them.

Obviously a straw-man, but also... justify it then? That's the point. You should be able to justify your position. "Cloud scale nosql db" doesn't tell me why you shouldn't choose it.

Post reply on HN