[kevinmhickey]

Wish I could upvote more than once. What I call "Resume Driven Development" creates fractured architectures and reduces quality in stable systems for the sake of "the latest standard". Not the best spend for the business or users/customers.

[cratermoon]

On the flipside, when your website only works with Internet Explorer 11, forcing your customers to keep an unsupported browser around, it's time to reconsider the aversion to keeping up with changes in the technology.

It's doubly bad when your website is designed for software embedded in kiosks and the like.

[JohnBooty]

If your legacy app is incompatible with modern browsers, yeah, that's got to change. No debating that, really.

But,

1. That may or may not mean a full rewrite of the app. Even in terrible old legacy apps, there usually is at least somewhat of a separation between the backend and frontend logic.

2. While not exactly uncommon, the scenario you describe is a subset of legacy apps. A lot of them work just fine, other than the fact that they're not in the latest version of the latest cool framework.

[Foobar8568]

I doubt all the code behind, dataset ridden ASP.NET got so easily replaced.... Or most JSP etc. There is an absurd amount of applications out there, hacked together over the last 20 years.

[colemannerd]

I highly doubt they work as well as an engineer believes. If there are no absolutely no user requested changes - even something as simple as support a new browser type or device type - then maybe. Otherwise, I've seen this viewpoint kill multiple companies because it lead to uncontrollable technical debt.

[nucleardog]

Keeping your software up to date as dependencies age and go out of support or the platform you build on evolves is not resume driven development. There’s a business and engineering case that can easily be made for that.

Of course there’s no real dictionary we can go to for this, but I’d define RDD as “chasing technology trends without business or engineering justification”.

Why are we switching to JS-Framework-De-Jour? Why are we using this graphdocumentjsondistibutedimmutablelog database all of a sudden? How does this improve the business? How do see a path to a positive ROI from this decision?

[cratermoon]

I think you just said "stay up-to-date with the latest standards", but in more words.

[simplotek]

> Keeping your software up to date as dependencies age and go out of support or the platform you build on evolves is not resume driven development. There’s a business and engineering case that can easily be made for that.

I'm not sure your false dichotomy holds. The definition of resume driven development is not whether there's a business case of not for a change, and the definition of legacy system is not the cost of upgrading it.

> Why are we switching to JS-Framework-De-Jour? Why are we using this graphdocumentjsondistibutedimmutablelog database all of a sudden? How does this improve the business? How do see a path to a positive ROI from this decision?

False dichotomies. You're assuming that not maintaining your software is free from cost or business impact, and you're assuming that switching to the latest and greatest does not bring any operational advantage.

[watwut]

Yeah, but on the other hand the "we ignore the resume thing" makes it increasingly hard to hire and keep people. Because when tech becomes too much legacy, developers can not afford to stay there. Your employees will be selected for more passive bunch. Or you have to pay more to keep them.

And I do work on project exactly like that. I am paid more then would be market rate for same position and everyone is scared we (as in seniors) are going to leave. It has advantages, not just in pay, definitely. But some of these advantages are disadvantages for the company to be frank ... like that the whole environment gets biased toward more passive and sort of sleepy. (If you are non sleepy you get pay raise, they are trying to reward it, but the force of the system is strong.)

It does not result in the best spend for customer or a company.

[jamesfinlayson]

Oof, I've seen this at a previous job - lots of microservices written in the newest/most dominant language of the time: Scala, Java, .Net, Python, Javascript, Coffeescript (!), TypeScript and Go services all powering one system.

[fbdab103]

Clearly the answer is to rewrite them all in Rust. /s

[hulitu]

They are still trying to compile the rustc because the new rust project won't accept the old compiler. /s

(i'm only half joking after seeing an error message like: you have rustc version 1.58.0, you need at least 1.58.1)

[jamesfinlayson]

Surprisingly I don't think there was any Rust - they seemed to have settled on TypeScript.