Comment by Cthulhu_ | Hacker News Reader

Comment by Cthulhu_ | Hacker News Reader

Parent Full thread

I've been working in consultancy for most of my career and have been in so many projects by now that seemed to be bullshit rewrites in $tech of the month; at least two projects where microservices were pushed through. The last one I was in was funny because while they had a small army of consultants and self-employed engineers vying for influence and carving out their own slice of the pie, the existing team of running, working, earning .NET software was just going about their day.

It was quite telling that after 1.5 years of that project, where all staff had already been replaced once, all they had to show for was a fancy product name and a presentation. And that the manager that led the project for ~2 years left right before or right when it went live - and he did that in a previous project too, where a working .NET backend for ecommerce was replaced with a Scala microservices on AWS system.

I did hear about the latter; I heard they went back to .NET, but the Scala services are still up and running and a maintenance nightmare.

But the lead developer got to play with his favorite tool and landed a job at lightbend because of it. Career-driven development, and I don't even believe he did it for his own career, but for self-gratification. Ecommerce is boring; REST APIs and a front-end are boring. But Scala, distributed systems, AWS, that's all cool and new.

I'm so tired.

New is not always better, but many times it is. We see this for example in programming languages, where newer ones incorporate the best features of their predecessors.

I think there are two things to be wary of: 1) Selecting a new technology just because it's hot, and 2) Refusing to consider new technology because the old stuff "just works." A good engineer looks at the requirements and selects the best tool to solve the problem while weighing the costs and benefits. Sometimes that's microservices. Sometimes it's monoliths. Granted, I don't know anything about the developers or business problems at that company, but to say that Scala microservices are just bad without justification doesn't sit right with me. It's all situational.

If an engineer comes to me and asks to use something like Scala, he'd better know all the upsides AND downsides (e.g. effect and streaming abstractions, ease of long-term maintenance, referential transparency, vs learning curve, hire-ability, 100 different ways of doing things, etc).

If new is not always better, then you’re stuck with the really hard job of knowing when it’s worth moving to the new thing.

Worse, you’ll be blinded by survivability bias. One easily notices the good rewrites and can easily ignore the bad ones.

Even worse, bad rewrites may be noticed in a place that a year or two ago was deemed a success story. I’ve seen many such cases due to misunderstandings or just political dynamics.

And lastly, don’t let that Engineer do Scala, they’ll brush off the compilation time regression and make all developers lives slightly worse (assuming the project is big enough)

Yeah, good point--when I said new wasn't always better, I was just talking about the case where the new tech solves a problem, but it's not the one you have.

Like choosing GraphQL just because it's new, even if your data doesn't have the structure for it.

Will have to disagree with you on Scala for several reasons I won't go into here--but the point was just that, in order to make these arguments in the first place, you need to do your research. Seems commonsense, but surprisingly many people don't do it (including younger me).

Reply on news.ycombinator.com