Hacker News new | ask | show | jobs
by cratermoon 1208 days ago
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.

2 comments

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.

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.
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.
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?

I think you just said "stay up-to-date with the latest standards", but in more words.
> 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.