Hacker News Reader

Comment by vinceguidry | Hacker News Reader

A lot of this boils down to the constant churn in frameworks, instrumentation, programming languages. Developers don't have time to master one way of doing things, it's just a constant lava layer of crap.

I took the time to learn how to build and maintain Ruby on Rails systems, hoping it would be the ticket to a fun, manageable career. Any project I worked on was an island of sustainable, fast development where the team finished the sprint's work in a few days. I knew where the bottlenecks were should the project need to scale, and scaling issues never took down the site completely.

Only to throw all that expertise away when it was just decided to replatform one day. Because I guess stable just wasn't good enough. After it happened twice, well, might as well go into devops. Y'all are gonna need it.

View on HN

I had the same issue with Rails as I have with Node : the churn is detriment to long standing projects. Most projects I do run for years and even decades; you go run an update for security for Rails code that is 10 years old. It is a nightmare. I did not have issues like that with php, asp.net or spring.

My experience has been the opposite. The Rails ecosystem makes updates straight forward and is very well documented. Been running various Rails apps for almost a decade now.

It's pretty good for incremental updates. It only asks a few hours a year to manage those.

Not so good when you want to upgrade a 5-year-old system. I inherited a reasonably well-built Rails app deployed with Ruby 2.2.1 and would like to update it, if only for security reasons. I can't even run that on a recent Ubuntu. On a system where I can run it, I run into dependency hell with the gems - need to upgrade some, pin lower versions of others. Possibly that could have been handled with pinned dependency versions the first time round, but that breaks the regular upgrade process.

That is indeed what I meant; I had to create debootstraps to even get it running on my laptop. And many of the gem updates broke the apis completely for no reason (move fast and don’t care?) I do not know: I remember a security update where the new version renamed most of the api methods while there was no reason to do so. I understand you can add new methods to keep backward compat; here they actually renamed functions so it was not backwards compatible and you had to change everything.

Simply put; we can cry about java or c# or php (raw php: not laravel; it has the same issues) but I can run 15 year old code on my current Ubuntu and it works fine. Maybe I need to change a few things but I do not have to rewrite a lot of it; it is more find/replace than anything. The feeling that software has to work in 50 years is important. Incremental updates are expensive and not needed for most companies, so software needs to support major version updates over decades. We know that now...

Straight-forward and documented is the minimum. Not having to think about it at all ever would be ideal. At some (huge) scale it will eventually become a thing that takes a year and a half and gets blog posts written about it, and I never enjoy losing a weekend to a microcosm of that: https://github.blog/2018-09-28-upgrading-github-from-rails-3...

This is the primary reason why I love the .NET stack so much. Not only is a security update almost universally a non-event, but so are major framework revisions.

Updating .NET applications for security concerns in many cases boils down to letting windows update do the thing it should already be doing automatically. In a much smaller portion of cases for .NET Core, a security update is a matter of rebuilding a self-contained deployment and pushing it out to production. Neither of these cases requires editing any code or configuration.

Only in the transition from .NET Framework to .NET Core did we find any appreciable difficulty, and even then it was still within the realm of reasonable. Most of the pain here boiled down to usages of System.Drawing and DirectoryServices, both of which have alternatives that are supported on all platforms. We opted to use the compatibility pack instead, but would be OK if that was removed at some point and had to replace with the other implementations.

We have lots of sourcecode that has withstood the test of time because of these technology choices. Many files are completely unchanged since .NET Framework 4.5 was released and now running flawlessly on top of .NET Core 3.1. This is the only reason we are still in business right now.

I ended my journey with NodeJS (and AngularJS on the same day) when I attempted to update all of my packages after just a month of inactivity. Seeing the resulting pile of nonsensical dependency graph trash in my console may have radicalized me into using more "enterprisey" solutions when writing software that I might get put on pager duty for.

I loathe NodeJS with the passion of a thousand suns. When Rails projects churn, at least you can rely on the stability of Ruby. With Node, the number of times I had to work around inconsistencies with the framework and even language were maddening. Babel is a horrible horrible thing, and Javascript was never meant to run on a server.

Maybe it's better now. But I won't ever do serious work again with the stack so I'll never find out.

Node is getting better each year imo. I've been pretty happy with ES6.

What makes you say Babel is horrible? Not disagreeing but I haven't heard anyone say that before.

People don't say it directly, but all the constant complaining about the bloat and complexity of the JS ecosystem and the size of node_modules folder boils down mostly to two tools: Babel and Webpack.

But that is a sign is it not? If tools as badly designed as webpack is the standard, is that not saying there is an issue with the entire ecosystem?

There are other standard tools that don't suffer with package bloat, like Prettier and Typescript, which don't have dependencies. This issue is not inherent to the ecosystem.

When people make fun of leftpad they are not talking about babel and webpack.

The bloat is a lot about the lack of a standard library in JS. Or rather, too many of the damn things. That and an inconsistent and unpredictable type system.

> The bloat is a lot about the lack of a standard library in JS.

Which is why someone created core-js, which a bunch of libraries use but, in my experience, never update. Every React project will have multiple libraries complaining that core-js 2 is deprecated.

So basically even the "fix" has all those problems.

> That and an inconsistent and unpredictable type system.

Agreed and honestly, I don't think TypeScript's solution for third party types is any better, either. I recently ended up in a situation where `some-library` and `@types/some-library` got out of sync and I simply had to try versions of `@types/some-library` until it would compile again. This happened because typedef versions are not pinned to library version in any way, they are versioned just like any other library, and to the best of my knowledge you can't simply look up this information to figure out which @types release you need for a library. You can only enumerate released versions and hope the latest of each work fine. Was there a breaking change that the typedefs haven't accounted for yet? Well guess what, you can't update that library, yet, even if there were security fixes. Your code won't compile.

This means you could potentially have `some-library` at version 1.2.1 and `@types/some-library` at version 1.1.0. There's no relationship there. This happens the moment there's a revision in a library that doesn't require a revision in the typedefs.

Sorry to ramble, I'm just really unhappy with the state of our two major ES languages.

Babel was the largest package that was dependent on leftpad back in 2015 when the leftpad issue happened.

The package bloat issue doesn't happen with Typescript, for instance, which occupies a similar niche in the ecosystem (it's also a transpiler), or prettier.

I don't think it's the tools' fault. They were built to solve problems, and they solve those problems quite well IMO.

Sure, but I don't think those things are related. It's possible to solve problems without causing package bloat. Typescript and Prettier have no dependencies, for instance.

I write JavaScript daily and my gripe with Babel (and transpilers in general) in the JS ecosystem is that it makes it easy to have 10 dependencies written in 10 similar-but-different languages. If you have to edit a dependency then you're stuck editing their source file (written in ES6-ES11 plus random unaccepted proposals / TypeScript / Coffeescript / Purescript / etc), installing their devDeps tree to run their build process, integrating their sourcemaps to un-break your stack traces, and writing code in a slightly different language each time you make a change. It's exhausting.

It's really neat that we have the option to transpile, and I was actively working on transpilers in the Meteor ecosystem when they were all the rage, but at this point I try to avoid them whenever I can.

Curiously enough JavaScript was in fact designed to run on the server too, Netscape LiveWire shipped it in 1995.

> After it happened twice, well, might as well go into devops.

My observation of the devops world is that the rotation of technologies and frameworks there is faster than in backend development.

True but imho its somewhat of a fan-out or at the very least knock-on effect. The explosion in devops complexity is a necessary byproduct of the explosion of projects that adopt new languages, runtimes, datastores, etc. No one ever fully deletes and retires the old system, so the overall environmental complexity grows exponentially. The tools it takes to solve those exponentially larger problems (k8s) look ridiculous when you consider them in the context of "a rails app with some node stuff". But they make perfect sense when you say "every quarter or two, for a decade, a dev team has adopted a new component or two into the stack. less than three of which have ever been deleted."

Yes, but there at least is some genuine innovation going on. The backend frameworks are just churn for solving the same boring and lucrative business problems in new, fashionable ways.

If you like Ruby on Rails so much, why don’t you find a job programming Ruby on Rails? There are so many.

He mentioned that he had a job doing that, but the company moved away from the framework without technical justification.

He could find another, but there would be no guarantee that the same thing wouldn't happen again.

> the company moved away from the framework without technical justification

I think this alone is enough justification to look for a new place to work, but I’m just a job hopping millennial.

I did. Asked to be moved to a different client. Still there.

My experience is that nobody actually does things The Rails Way, which is where most of the benefits come in. No, they’ll start out in Rails such that their underlying data model evolves into a huge mess (because Rails guards against most problems in the code layer, so the data model problems don’t really appear as bugs yet), and then some resume-driven developer will push for serverless or microservices to solve scalability problems (when the actual bottleneck is the database and the data model, not Rails), and now you’re left managing this Frankensteinish “rails” SPA beast that could be rewritten as a proper database schema and a 5K LOC Rails app, but there’s too much change control process to actually achieve that.

Rails does so much of the plumbing work for you (and does it really well) that it’s a good smell test that if you’re not working on something that the user sees, you’re probably reinventing the wheel.

The biggest waste of time I've ever seen in my career was when a team put all their backend efforts into migrating their app from The Rails Way to Services, then from Services to Trailblazer, then from Trailblazer to ActiveInteraction. All in the span of two years and without delivering a finished product.

In the end the company just bought a competitor and gave up on the app.

100% agree that doing things The Rails Way is where you reap the benefits.

After it happened twice, I just gave in to the inevitable and decided to value jobs based on other factors.

> I guess stable just wasn't good enough

I suspect that's meant to be rhetorical, but from a business perspective, was stable good enough? Sometimes what works now won't be competitive in the near future.

> Sometimes what works now won't be competitive in the near future.

What do you mean by that? I can understand in terms of hiring devs, this is true, but any other reason I would be curious about. Because I work with/in many companies, I see a lot of different tech and competitive is usually just what the team knows best. So unless you are making a new team, I cannot phantom why you would switch.

Java with Servlets/Spring and C# with asp.net have been competitive for almost 2 decades; maybe some people can shave off a few minutes here and there but in the grand scheme of a serious company with a serious project (500k loc+) it is not going to matter. There are exceptions as for instance machine learning but those gaps close and this was about web frameworks.

Perhaps he means that you won’t be able to attract great talent. A lot of extremely talented engineers don’t want to work on code bases and technologies that are 15 years old.

Definitely would like a source for this because I feel like I hear it a lot and I don't believe it's true.

You can be talented and not care what you work on. And if all you care about is what tech is new and shiny, how talented can you be? I don't want you rewriting my product every year so you can use the next framework du jour.

Maybe talent means something else when nothing is at stake, but I'd argue that a talented engineer knows that when a product works and makes money, and the tech stack isn't prohibitive of those goals, it doesn't really matter what it's written in. In fact, I see trend-chasing developers as liabilities, because they're the ones who will replace everything every six months while you bleed money.

> they're the ones who will replace everything every six months while you bleed money.

Yep. I agree. Maybe talent is the wrong word, but my point is that a lot of experienced engineers want to learn new things by working on new things.

There is a difference between talent and wisdom.

My source? Decades of experience in the industry working with hundreds of different engineers. So, anecdotal.

Not everything needs a double-blind research study to be truthful.

The issue is rarely the age of the codebase or the tech stack, but rather the maintainability and quality of the code.

Due to many factors, the age of the codebase is normally inversely proportional to its code quality. Especially codebases in fields where trends change fast, like web technology.

Therefore, if you're a talented engineer able to work in multiple technologies you'll certainly prefer to work on something that has less chances of making you want to tear your hair out.

> the age of the codebase is normally inversely proportional to its code quality.

What??? You are saying that simply because a code base is old, it is of poor quality. There are numerous public examples contradicting this: Linux, many Apache projects such as httpd, etc.

I emphatically disagree and would like to know why you think that.

I said "normally". I don't think anyone considers Linux or httpd "old tech", neither they are "legacy software" that experienced developers are running away from. C might be old as a language, but there are still modern things being built with it. I also said that the issue is not the age itself or the tech stack.

You didn't use the word legacy in your post. You used the word old. Quite different. Something can be old and still maintained (httpd, etc).

both java and .net (core) are evolving and more mature, though

Take a new site for example

Its just text and pictures on a web page. The new york times re-invented a database out of kafka to power theirs (mind bogglingly stupid)

The Guardian re-wrote their CMS at least 4 times, at a cost of well over 50 million, if not more. Thats before they got to re-doing the layout.

The FT spent 6(!) years rebuilding their entire stack, (150 tech staff for 6 years. a good percentage contractors. > £70million)

All of it is just fucking text on a fucking web page. All that effort to add fancy gizmos for hosting, optimising for framework x, which has a half life of 6 months, adding animation to drop downs. Just a spectacular waste. They are still re-platforming every 9 months, each of the 5 major teams.

All of that money could have been put into content, advertising for customers, collaborations & events.

Most news sites can get away with a static, highly cached system (I mean look at the Daily mail, the page is slow, static and looks like shit, yet its the biggest new paper site online)

So form a business perceptive, its spaffing money up the wall for no real gain.

can confirm. media companies spent the last decade alternating between redesigns and cms migrations in a circular path that went nowhere while fb & goog ate not just their lunch but their breakfast and dinner too. the vast majority of it was driven by engineering-management-career resume-building and was actively detrimental to the editorial/content-production/journalism side of the house.

> [T]he vast majority of it was driven by engineering-management-career resume-building and was actively detrimental to the editorial/content-production/journalism side of the house.

Why didn't the non-technology side prevent this if it was so clearly detrimental? I can't imagine that the technology side of a media concern has that much influence over the company's overall priorities.

because editorial say: "we want the website to do x" the tech team say ok we'll need 100 staff, and six months.

then, after delivery, the tech team "we need 50% more staff to do this thing, its really good, it'll save 25% in our hosting costs"

Editorial then say: "sure, deliver this feature as well"

This continues, and then deadlines are missed. So tech say: "We have so much tech debt we need to re-architect" which allows ego/CV driven design.

I've tried to reply to this three times and its hard to without writing a book.

The shortest possible answer is that investors/owners/boards were watching what happened to sites like reddit/huffpo/bi/instagram/tumblr and salivating out of control at the word "billion". They believed that if they starved their editorial operations and bet most of the cashflow on growing their tech teams that "user generated content" would make up the difference. It was very simple math that said "media companies are valued at 10x profits, tech companies are valued at 10x revenue, lets do whatever we can to give the appearance of being a tech company not a media one".

Within those companies tech departments it became open season for CTOs, VPEngs, DevOps Directors and sr/lead/architect devs to engage in a peer-to-peer-ddos of architectural and tech-fad-chasing ones-up-manship. Because the only penalty for it all turning out to be too much was having to grow your headcount.

In 2016/2017 it all finally collapsed. Most of the companies have faded to layoffs and/or acquisitions. Many have basically frozen and given up on their tech stacks in-place. A large number have abandoned ship to wordpress (where imho they should have been all along).

Sometimes I wonder what the general state of "the media" or "journalism" would be now if 80% of that money had gone to hiring content creators, or even just paying the same number of content creators the 30% more it would take for it to be an adult job not a early-20-something job. An awful lot of the salaciousness and outrage-stoking in media right now is a byproduct of the actual jobs being very young people sitting in place all day garnering all their information from social media feeds and trying to hit their 2 - 5 posts (sorry 'articles') a day quota. We all think we're critiquing journalistic institutions when we point it out but really we're just yelling at kids. Blaming them for not being able to achieve the standards we're used to with 3 hour to deadline in their permalance gig, when what we got used to was written by mid-career people with benefits who had all day and sometimes week.

Media isn't stoking outrage culture, its clinging to it as the last source of pennies left before the nothing.

I wish I could upvote this a thousand times. At the end of the day, it's all ego driven development. Nobody wants to think that their job has already been solved, and what's left is mundane and boring [engineering wise]. And so the business ends up with using a distributed log to handle a data set that could fit on a big thumb drive.

Reply on news.ycombinator.com