Remix clone Hacker News

The article is about modernization projects, which have soft deadlines because ostensibly the legacy software is still running while you're developing the replacement. There's always budget pressure, and promises may have been made, and users may be hoping for new features and eliminated frustrations... but if the replacement is a day late, it really wouldn't matter much.

Conversely, if you're trying to launch a space probe and the planets are no longer in the right positions for the required gravity assist, your spacecraft will not get where it needs to go. Or if you're a little $100M/yr toolmaker, and Ford asks you for a die for the 2026 F150 production line, to be delivered by March, and the contract states you owe a $20,000 per MINUTE penalty if you're late...you don't wait until February to say something surprising happened and it's not going to be ready. You don't sign on that dotted line unless you know for certain that you can do it.

Ford or NASA won't bat an eye when you tell them that a quote is going to cost $XX,XXX. They won't be surprised when they give you an ECO and you say that it's going to take 3 weeks and $8,000 to deliver a part that everyone knows you can probably make by hand in 30 minutes, they know that you're hedging against those deadlines, and pricing in the acceptance phase and inspection phase and contingency plans and everything else that makes their deadline-heavy industry function.

But if you tell someone at OP's modernization group that due to incomplete information you think that the 30-minute task to change the text of that button will take "no more than 3 weeks and $8,000" they'll laugh you out the door. Optimistic estimates get rewarded, pessimistic estimates get discouraged, accurate estimates are irrelevant, and in the end you're constantly behind schedule and no one's really surprised.

▲

analog31 6 days ago | parent [-]

One technique is to run the modernization project, but use maintenance of the legacy software to keep the business going. Such maintenance could be for keeping up with hardware changes, OS upgrades, new features, and so forth.

I've seen projects run in parallel like this for 10+ years.

▲

Tostino 6 days ago | parent [-]

I just got done doing exactly that with my old SaaS I built / worked on for a decade.

Went through a roughly 3 year rewrite process while utilizing maintenance mode on the framework I had originally decided on back in 2014 and which sadly had an "upgrade path" of "you look like you could really use a full rewrite for your entire frontend" to get on the very next major version in like 2016. I'd say the main "use" for utilizing their maintenance support, was the fact that they would still fix issues with browser incompatibility, security issues, etc.

Like the fact that back in the day Chrome changed background tabs to no-longer respond to push notifications unless they are the active tab (after some delay)...it broke things in our app. But luckily we able to lean on the vendor for those types of issues, because there was very little my team could do to make a rewrite of a massive webapp any faster than it was already going.

Glad it's done, and I am out.

▲

mattmanser 6 days ago | parent [-]

I've been doing this a while now, and as far as I can tell, there's always a way to run two frameworks side by side and migrate. And existing users get new stuff right away.

I've done it backend, I've done it frontend. With web apps it's always possible, it's the fundamental nature of the web and browsers.

Frontend is trivial because of how browsers work, every page could run a different framework if you were that mad.

Backend I've had two frameworks on one server for multiple migration projects. There's usually a way unless you're switching language.

But worst case scenario, say you wanted to change everything, I'd stick a load balancer in front. Route according to the end point requested. Then gradually migrate end points. You might need some craziness around authentication, but that's the sort of issue that is solvable with a week's work by a single, good, developer.

What was so complicated that stopped you doing that? Genuinely interested.

	▲	Tostino 6 days ago \| parent [-]
		That is actually part of the "extra support" we decided to pay for. The application was originally written in Vaadin 7, Vaadin 8 had an absolute ton of breaking changes and we could not migrate in time, and then the breaking changes continued to compound as new releases happened and they migrated away from GWT, making a "big bang" rewrite not practical. Their extended support included a tool called multi-platform runtime, which allowed the old application and new application to be run side-by-side and each section replaced one at a time. So that is essentially what we did. Still took 3+ years to do the rewrite.