[goto11]

The key is identifying which parts of the code needs to be adapted or replaced and which do not. If the code is well designed with separation of concerns, replacing a framework or library or external dependency should not require all the code to be scrapped, just the layers directly interacting with replaced part.

Some trivial applications are basically just glue between frameworks, but most non-trivial application of value will have lots of code which is not tied to any particular framework, and often this is the most valuable part of the application.

Scalability is improved by identifying the bottlenecks and improve the design at those core points - not by rewriting everything from scratch.

I guess moving to a different programming language is a case where you literately have to touch all the code, but even then code can often be ported semi-mechanically instead of starting from scratch.

[zerbinxx]

In my experience one of the main reasons for wanting to scrap code is not only that it has scaling/other tech issues, it also has very poor separation of concerns.

Granted, that concept can and should be introduced into old codebases. Last year my team successfully warded off the Sirens of Rewrite by just doing the hard work of extracting all of the dead framework calls and then NOT adding them back in drag-and-drop style, but properly exposing them through interfaces that don’t require everything to know everything about the particular replacement framework we used.

[usrbinbash]

> If the code is well designed with separation of concerns,

"If" is the operative term here. "If" it is well designed, then there is usually not alot of reason to scrap it in the first place.

[goto11]

Sure, but my point is, if the code is not well designed, the result of a ground-up rewrite will not be well-design either, for the same reasons which caused the scrapped version to be badly designed.

It is even likely the new version will be worse, since it wont be developed incrementally, and that harsh deadlines will be imposed when the organization realize they can't evolve the product as long as the ground-up rewrite is underway.

[usrbinbash]

> Sure, but my point is, if the code is not well designed, the result of a ground-up rewrite will not be well-design either,

That doesn't follow for me, sorry.

A rewrite, as I understand and use the term, doesn't mean transpiling what exist to, say another language or to another framework. The old version is essentially just a very detailed and testable list of functional requirements; everything the old thing can do (as long as that functionality is still actually useful), the new thing must be able to do as well.

How this functionality is implemented in the rewritten version, and how it's internals are designed, is entirely up to the rebuild. The way functionality is implemented in the predecessor does not necessarily determine how it is implemented in the new version.

[goto11]

If the rewrite is by the same organization, the same forces which caused the first version to be badly designed will cause the rewrite to be badly designed.