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

31–40 of 269 posts

Re: Choose Boring Technology (2015)

#31

Post by dwedge »

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 had exploded in popularity and it had coped with it fine because the infra team were already handling the stack and it wasn't some snowflake deployment.

Does anyone remember the post I'm talking about?

Re: Choose Boring Technology (2015)

#33

Post by insanitybit »

i_like_robots wrote: post #29
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…

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 the tech industry used to be, people reference this post today.

> around this time because teams had taken bets on new tech either they didn't know how to use well or the tech didn't take off and was a dead end.

Yes, they should have had a discussion about their requirements and which technologies would have solved them.

> Then you consider it boring.

Then "boring" is useless and you should just say "I know this technology well and it maps to our use case well" and be able to justify that.

Re: Choose Boring Technology (2015)

#34

Post by [deleted] »

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…

[deleted]

Re: Choose Boring Technology (2015)

#35

Post by insanitybit »

geodel wrote: post #30
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…

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 perfect in every single case but they do increase success chances for even sub-par teams as opposed to "rigorously evaluating latest technology"

Rule of thumb. And it's not a rule. It's a bias based on a vague term.

Re: Choose Boring Technology (2015)

#36

Post by exabrial »

nawh. 50x node modules, typescript out the wazoo, all the state in the client (where you can't see it in prod), the most over-complicated UI, paired with async callback spaghetti is what you do these days.

We're "scalable" over here. It's a sexy problem to have.

Re: Choose Boring Technology (2015)

#37

Post by dwedge »

theptip wrote: post #9

I love this post. It’s also interesting to revisit in the age of agents. Using the language of the article, I’d say “push all your innovation tokens into agents” is probably a good move. This means the tech your agents work with should all be boring tech. Another way of saying this is “use in-distribution technology”. If agents are substantially better at Rust than Zig, probably you should use Rust, even if Zig is “b…

It's a total tangent but AI being so good at developing rust means that my first impression of seeing a rust project has totally changed.

4 or 5 years ago if I had to weigh up two options and one was written in rust it was almost a sure thing that the program was snappy, fast, reliable and that the author was competant.

Now it's a sure fire sign that the project was probably vibe coded. Not saying it can't still be good, I just have a different first impression now

Re: Choose Boring Technology (2015)

#39

Post by geodel »

insanitybit wrote: post #27
bravura wrote: post #26

Earlier quoted context omitted.

"boring" means familiar. It should have more known unknowns than unknown unknowns.

So then say that.

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

Re: Choose Boring Technology (2015)

#40

Post by dwedge »

add-sub-mul-div wrote: post #15
epolanski wrote: post #13

Earlier quoted context omitted.

One thing I learned about AI is that, e.g., if you're making websites you're much better off going for php/ruby/elixir, even if you don't like the languages much. Pipelines and deploys gets much easier and faster than the very common TypeScript monorepo, and so does communication between server and client. And I say that as a TypeScript and Effect aficionado who has no particular love for neither php or ruby, but the…

The willingness to reshape society for the benefit of AI rather than shaping AI around humanity paints a very dire picture of the coming decade.

I disagree. We've been doing this for two decades already. A lot of monoliths were rewritten in a way that best fit the AWS pricing model of the time with the software itself seemingly being an after afterthought. (I'm not here to discuss whether monoliths or micro services are better, I'm just saying the choice of how they were rewritten was too often mostly for AWS pricing)
Post reply on HN