Hacker News Reader

Comment by pocketarc | Hacker News Reader

It's interesting to now be at a point where we see a generation of SaaS make way for the next generation of SaaS.

I've come to realise that realistically, platforms -do- change, and eventually you will need to either commit to a rewrite (even if you choose to do it by spinning up a whole new company like Freshbooks did).

As an example, a SaaS app from 2010 might have been barely responsive, might have been put together with jQuery, and the backend might've been written in a framework that died off in the meantime. And while you can do a lot of little improvements and refactors here and there, ultimately the foundation on which you've built your system gets to a point where it slows you down more than it benefits you, and there's no real way forward.

The stories in the article make me think that the old adage of "never rewrite" is really more like "eventually you will either rewrite or die".

View on HN

I’m a Tech Lead for a SaaS product that’s been around since ~2010. Four or so years ago we stared piecemeal transitioning away from jQuery/Backbone to React. Nearly all of our main UI is React now, but it’s still pretty coupled to Backbone. There’s a lot more risk removing that, so we’ve not had enough of a reason to yet.

Basically the high touch (from a developer point) areas of the app are always the most modern and the first place to get whatever treatment we transition to (React, typescript etc) and there’s some really untouched areas that might remain prehistoric for years, and that’s fine.

Its worked pretty well for us, and I can’t see why it wouldn’t continue that way.

I'd call that a continuous rewrite, which is also the strategy that worked best for me. If you're not willing to make these investments as you go, you may well end up in a full-rewrite-or-die situation, I suppose. Comes down to how aggressively management prioritises short term results. I personally have never worked on a code base that far gone, but I can imagine they're out there.

The big risk of letting the high touch areas be what get migrated to the modern stack, is that for many companies this is largely driven by the fashion of new hires. And letting new hires drive the technical choices isn't necessarily bad, but you do have a major risk of them not understanding why things were there.

I'd say, historically, you were also lucky in the timing. The last 4 years have been absolutely rock solid for frontend development, compared to the time before. Still way more fluid than I personally think it should be, but I'm willing to ack that things have gotten a lot more stable.

Oddly, the backend has gotten worse in these years. The amount of service related churn that has happened in the past decade has been impressive. And mostly not in a good way. I can hope that we are going to be a bit more stable now.

High touch in the sense of being driven by product development. We let everyone make technical choices, sometimes autonomously but sometimes as a pitch. A part of technical leadership in smaller organisations is mitigating a lot of that “new hire/shiny thing” risk.

We used react a lot externally to the main product as early as 2014, but didn’t introduce it into the main product until we were comfortable.

Apologies if it felt like I was questioning your choice. I meant my post as an addition.

Using things outside the critical path is definitely the right choice. Making things to throw away is also great.

I do get worried, sometimes, that it is also correct to let the new coders pick the styles and frameworks. Letting them choose is a huge boon to their productivity. And letting them advance on a bet like this can payoff really well. Just expect losses along the way.

The old adage is more “never do a big bang rewrite”, where the launch of v2 is one big step. An incremental rewrite, where perhaps you change a single component or bit of the UI, is always necessary. Although even there people moan about “change fatigue”.

In a large enough system a full rewrite becomes impractical anyway, because the team is sized to incrementally grow not replace whole cloth. The team simply isn’t capable of rewriting the whole codebase in one big bang release in anything less than years.

You can bring up a larger team for the rebuild but that introduces its own risk, or you can leave customers out in the cold for years, like netscape did.

Continuous rewrites are the only way to handle that kind of system, just like in a large enough city just to keep up with natural decay it becomes necessary to always have construction and road works projects going on.

Reply on news.ycombinator.com