Hacker News Reader

Comment by translucyd | Hacker News Reader

As a mid-seniority developer, I'm just now starting to grasp the harsh reality of a full refactor. We always think we can improve the speed and code of a website but, man, that's really though.

I always remember the "let's throw away Windows ME codebase for NT" scenario. Sometimes giving up is better I suppose.

View on HN

>"let's throw away Windows ME codebase for NT"

Well the Windows 9x codebase was always mean to be , eventually, thrown away. It existed only to be able to run the OS on very low hardware (eg Win95 run even on 4 MB of RAM).

Certain websites are so overbuilt though that theres plenty of low hanging fruit. I’d say a very healthy majority of the websites I visit could replace whatever bulky mess they have with static html and still serve me their content and ads. Then the website would probably be orders of magnitude more performant refactored in html.

This is why we have the strangler pattern, it's not just for backend apps. Start small, tackle the biggest risks first, deliver incremental value.

I have been part of 2-3 strangler refactors... I don't think we ever reached the turn off the old app part.

Did you end up with a net improvement, though?

Me too, but I don't see that as a failure. Sometimes it's a case of 80/20, and refactoring that 20% might just never be worth the effort.

One of our teams rewrote their legacy cloud product in an interesting way. Instead of gradually replacing components of the existing product, they forked it, rewrote most stuff from scratch in a different branch using a different stack (different UI/UX also) and called it version 2.0. The old version was still maintained (bugfixes, tech support etc.) but they stopped selling it. Instead, they started selling version 2.0 (new clients were unaware of the difference). Version 2.0 did not have full feature parity with version 1.0 at the start because it would take years to reimplement everything. What they did was gradually migrate clients from 1.0 and 2.0. Most clients did not need all the features so they were OK with version 2.0. Those clients who refused, stayed on version 1.0 for a few years. Then the team was slowly adding more and more features to 2.0 for the next few years, and more and more clients were willing to migrate, and this year the last client migrated to version 2.0. It took 4 years overall. The new version was designed to be more stable, more scalable and more maintainable, so it's a net win in the end. Also, since it was basically a new product, they were able to experiment with new ideas without the constraints of the old product.

There's usually a subset of any given codebase that gets changed substantially on a regular basis, and the rest mostly stays mostly the same. If you can get the parts in the former category replaced with something better to work with, that often gives you most of the advantages and you can migrate any remaining bits as and when you can be bothered.

>We always think we can improve the speed and code of a website

You're not wrong, but the moment you speed up your site to being usable then the stakeholders above you are going to add 50 more (conflicting?) requirements until the site is slow as the old one.

Reply on news.ycombinator.com