> The forces which have caused the previous project to accumulate technical debt are still in effect, so after the rewrite reaches feature parity you will probably have exactly the same amount of technical debt.
I would expect, based on both theoretical grounds and on past experience, that the rewrite will have more technical debt by the time it has reached feature parity.
Assuming your primary source of technical debt is all the little corners that get cut in order to meet a schedule, and assuming that the rewrite is being given far less time to get to a certain level of functionality than the original software took to get there, then one would expect the team to need to cut more corners to finish the rewrite. The code may be in a fancy new language, and it may be built on a more modern technology stack, but, in the mad rush to get a death march project done as quickly as possible, corners were cut.
If it feels otherwise, it may be because the project you're replacing was particularly messy. But probably it's because the design tradeoffs in the new system were made by yourself and your colleagues instead of that deranged pack of yahoos who were running things in the '00s.
> Assuming your primary source of technical debt is all the little corners that get cut in order to meet a schedule, and assuming that the rewrite is being given far less time to get to a certain level of functionality than the original software took to get there, then one would expect the team to need to cut more corners to finish the rewrite.
That's a good point, but it considers only “internal” technical debt. Legacy platforms often have “external” technical debt that you are carrying, especially when they are unsupported by the original vendor. Rewrites are often motivated by the desire to escape this external technical debt, and end up trading a reduction in external technical debt for an increase in internal technical debt.
100% this. I've also seen a lot of cases where the rewrite is partial, and integrated with the legacy system to preserve end to end functionality, as they don't have enough time to do the full feature set, migrate all the data from the legacy system etc.
You then end up with a hydra system, where you need to understand both legacy and rewrite systems, and their interactive, increasing the complexity even more!
I would expect, based on both theoretical grounds and on past experience, that the rewrite will have more technical debt by the time it has reached feature parity.
Assuming your primary source of technical debt is all the little corners that get cut in order to meet a schedule, and assuming that the rewrite is being given far less time to get to a certain level of functionality than the original software took to get there, then one would expect the team to need to cut more corners to finish the rewrite. The code may be in a fancy new language, and it may be built on a more modern technology stack, but, in the mad rush to get a death march project done as quickly as possible, corners were cut.
If it feels otherwise, it may be because the project you're replacing was particularly messy. But probably it's because the design tradeoffs in the new system were made by yourself and your colleagues instead of that deranged pack of yahoos who were running things in the '00s.