6 ms·

> ...that is a high-risk approach that is usually without correspondingly high payoffs That's probably true, but it's also true that over a long enough timesca

> ...that is a high-risk approach that is usually without correspondingly high payoffs That's probably true, but it's also true that over a long enough timescale (100 years, to trigger a reductio ad absurdum) there is a very high risk that not replacing or rewriting that code will sink your technology and possibly your organization. Just because the risk will be realized in the long run doesn't mean it's not a risk. And if the worst-case scenario is death of the entire organization, then the math could very well add up to a full rewrite. Most business managers are not prepared to think strategically about long-term technical debt. It's the duty of engineers to let them know the difference between "not now" and "never". And the difference between "urgent" and "low priority".

mentat 11y ago
It boils down to "don't change the implementation and the interface at the same time". It doesn't say "don't ever change the interface".
Avshalom 11y ago
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.
ksk 11y ago
>but it's also true that over a long enough timescale (100 years, to trigger a reductio ad absurdum) there is a very high risk that not replacing or rewriting that code will sink your technology and possibly your organization. Could you elaborate on what basis you claim this as a truth?
- humanrebar 11y ago
  It's largely conjecture, admittedly. But there are very few pieces of software that last 40 years. Most companies don't plan to be out of business in the next 40 years. And many tech companies have gone out of business in even the last ten years because they weren't agile enough to adapt quickly to new technological changes.
  - ksk 11y ago
    While I agree that in the abstract, technical debt can catch up to you, I'm just not sure that its impact is necessarily such that it cannot be contained or mitigated. I mean UNIX is still around for 30 odd years. It hasn't sunk. It carries tremendous technical debt, in terms of bad design, in terms of implementation bugs that need to be carried forward, etc. My sense is that the more organizations that depend on a piece of tech, the more chance there is that it is going to age well, warts and all.
  - bcbrown 11y ago
    I don't think that argument holds. Usually it's true, that if something hasn't lasted a long time, it likely won't last a long time in the future. But we live at a quasi-special time, close to a boundary condition. There exists no software that has existed for 100 years, because software was invented sometime in the past hundred years. You can reductio ad absurdum that argument by saying, the week after the first software was written, that no pieces of software have lasted more than a week, and therefore very few pieces of software will last more than a week. So very few pieces of software have lasted 40 years, because very few pieces of software were written at least 40 years ago.

mentat 11y ago

It boils down to "don't change the implementation and the interface at the same time". It doesn't say "don't ever change the interface".

Avshalom 11y ago

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.

ksk 11y ago

>but it's also true that over a long enough timescale (100 years, to trigger a reductio ad absurdum) there is a very high risk that not replacing or rewriting that code will sink your technology and possibly your organization. Could you elaborate on what basis you claim this as a truth?

humanrebar 11y ago
It's largely conjecture, admittedly. But there are very few pieces of software that last 40 years. Most companies don't plan to be out of business in the next 40 years. And many tech companies have gone out of business in even the last ten years because they weren't agile enough to adapt quickly to new technological changes.
- ksk 11y ago
  While I agree that in the abstract, technical debt can catch up to you, I'm just not sure that its impact is necessarily such that it cannot be contained or mitigated. I mean UNIX is still around for 30 odd years. It hasn't sunk. It carries tremendous technical debt, in terms of bad design, in terms of implementation bugs that need to be carried forward, etc. My sense is that the more organizations that depend on a piece of tech, the more chance there is that it is going to age well, warts and all.
- bcbrown 11y ago
  I don't think that argument holds. Usually it's true, that if something hasn't lasted a long time, it likely won't last a long time in the future. But we live at a quasi-special time, close to a boundary condition. There exists no software that has existed for 100 years, because software was invented sometime in the past hundred years. You can reductio ad absurdum that argument by saying, the week after the first software was written, that no pieces of software have lasted more than a week, and therefore very few pieces of software will last more than a week. So very few pieces of software have lasted 40 years, because very few pieces of software were written at least 40 years ago.