3 ms·
> re-implement it first then improve it Right. I'm saying (poorly, I guess) that that doesn't always work. If the technical debt is sprinkled throughout your s
by humanrebar 11y ago
> re-implement it first then improve it
Right. I'm saying (poorly, I guess) that that doesn't always work. If the technical debt is sprinkled throughout your system or your organization is sunk deeply into a broken paradigm, you're in trouble. Sometimes you need to provide a completely new technology that serves many of the same use cases in a different way.
I'm not saying we should reach for rewriting things as our first instinct.
I am saying that your COM interface will need to be replaced some day. Or your COBOL business logic will become a liability. Or your frames-based web API will cost you business.
Incremental change leads you to a new local maximum, but sometimes that local maximum stunts your growth or even proves deadly.
- azernik 11y agoOne strategy that I've seen work for this kind of deep architectural change is to write the new system, then write a shim that provides a compatibility layer (however hacky and ugly) to emulate the old system. This lets you test the new system without then having to also test everything that the system interacts with. And then, start replacing usages of the shim with direct interaction with the newer prettier system. Think the win32 to NPAPI transition.
- leonardinius 11y agoI believe you are describing http://www.martinfowler.com/bliki/StranglerApplication.html http://www.martinfowler.com/bliki/StranglerApplication.html and particularly http://www.martinfowler.com/bliki/AssetCapture.html http://www.martinfowler.com/bliki/AssetCapture.html
- azernik 11y agoYup! Loved that article when I first saw it on HN - I felt it described well a lot of upgrade projects undertaken at my then-employer.