Hacker News Reader

Comment by inimino | Hacker News Reader

You really missed the point. It's not "there is an older way that works fine". It's that there is a simpler way that can be built in less time, takes fewer developers to maintain, will have less bugs, performs better, and is more reliable, because it's simpler than all the crap that people want to use. But people will insist on using all the trendy crap because it's trendy, FAANG is using it, it looks good on a resume, etc, etc.

View on HN

If all those were actually the advantages of established technologies, you would have a point. But anything that does something useful is inherently complex. To someone who's been programming for 25 years, sure, sed/Perl/Makefiles are straightforward and well-established. But to everyone else, to build or modify them, first you have to go back and learn Perl and sed, which are both riddled with layers of historical baggage, gotchas, and divergent dialects.

You can't actually get all of those things: speed, team size, low defect rate, high performance, high reliability, simplicity, as they are at odds with each other. Generally, the rule is "good, cheap, fast: pick two."

The post you originally replied to listed specific technologies that purely add complexity when introduced to a project. Hadoop isn't replacing something equally complex, it's simply adding complexity. Now if you simply can't do with anything else, and you're at the point of rolling your own distributed filesystem and job scheduler and zookeeper and all the rest of it, then sure, try Hadoop, but that's not what we're talking about. Note that I can pick on Hadoop because the hype cycle has peaked there, but this applies to plenty of newer techs where it hasn't.

You literally can get more of all the good things in my list by removing unnecessary complexity from a project. And yes, there really are some technologies that, most of the time you see it being used, the entire project would literally be better off with literally nothing in place of it. And yes, people still prefer to use the trendy thing.

Fair enough, if replacing that complex of a stack with Python/Makefile/cron is even possible, then it's over-complicated and you can refactor the complexity away. Unless of course you will soon need to implement a feature that requires bringing back in that whole stack. But I suppose this is why hindsight is a valuable asset when you get a project in maintenance mode, as you can see where the peak complexity of the project actually ended up being.

I understand your point, but a minor retort: You get the same sort of "gotchas", historical choices, baggage, etc from new-ish code that does "too-much" and can be considered black-box "magic" without delving into it, reading docs, tutorials, and having sometimes just plain having experience in it.

I think a potential overarching point that started this thread: Tech should evolve, but it should also stay steady and simple to use. Too much of the "new" stuff is not just a good natural evolution of people solving problems, it's people adding layers of complexity and fluff where there need be none.

> Too much of the "new" stuff is not just a good natural evolution of people solving problems

I guess it depends on what you're lumping in with "new stuff". I've experience the opposite quite a lot of refusal to acknowledge that a new constraint or condition has modified the parameters of what a solution is trying to solve, dismissed as one off events or something to monitor, then 6 months later when the problem was isolated becoming the new norm, and monkey patches being required because of refusal to acknowledge that the environment has become more complex.

Unless you plan to work at the certain job until you retire, you gotta think about your resume. You don't want to be the guy looking for jobs with Visual Basic and Excel macros experience.

Your job as developer is not to improve your CV, you need to solve a problem and you should use the best tool for that job not what looks cool on your CV, you should use cool shit on your own time not attempt to force on your work project latest cool stuff and 1 year later leave and let the rest deal with the fallout.

I think your resume looks really good if you explain that you solved complex problems with Visual Basic because it was the right tool for the job given the circumstances. If it’s the only thing you know, maybe not.

Reply on news.ycombinator.com