5 ms·

I think jerf was trying to say that when re-implementing something, re-implement it first then improve it, don't do both at once.

jerf 11y ago
Bingo. That means even if your new pretty-shiny is going to eventually have a new API, it is usually worth it to still offer an old shim in with the old interface. It may seem like extra useless work, but it reduces risk. Far be it from me to suggest rewrites are never useful. Half my career could be characterized as "rewriting the things nobody thought could be rewritten because they were too messy and entrenched". It's personally a bit risky (you end up owning not only the bugs you created, but the bugs you failed to reproduce... doubly-whammy! better be good at unit testing so at least the new code is defensible), but the payoff is pretty significant, too, both for your career and for your organization.
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 ago
  One 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 ago
    I 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 ago
      Yup! 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.
ghthor 11y ago
This koan also keeps your change history coherent which will likely be useful for the person that has to fix it later.

jerf 11y ago

Bingo. That means even if your new pretty-shiny is going to eventually have a new API, it is usually worth it to still offer an old shim in with the old interface. It may seem like extra useless work, but it reduces risk. Far be it from me to suggest rewrites are never useful. Half my career could be characterized as "rewriting the things nobody thought could be rewritten because they were too messy and entrenched". It's personally a bit risky (you end up owning not only the bugs you created, but the bugs you failed to reproduce... doubly-whammy! better be good at unit testing so at least the new code is defensible), but the payoff is pretty significant, too, both for your career and for your organization.

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 ago
One 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 ago
  I 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 ago
    Yup! 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.

ghthor 11y ago

This koan also keeps your change history coherent which will likely be useful for the person that has to fix it later.