Rewrites often start off with the assertion that the current code is buggy and can’t be fixed.  The replacement code will fix all of the problems because the technology will be better, the devs have improved, or for any other reason.

The rewrite project will get off to a great start, but before production, it will run into The Two Clock Problem.

What is the Two Clock Problem

The Two Clock Problem occurs when you have two clocks that run at different speeds.  One clock must be wrong.  With only two clocks, you can’t tell which one is wrong.  Even worse, the second clock can also be wrong.

Rewrites Have Two Clocks

The first clock is the original system.  The second clock is the rewritten system.  They produce different answers.  The original system was deemed unreliable, so different answers should be a good thing.  Except that different doesn’t mean correct, it means different.  Both systems could be wrong.  Sometimes, the original system is correct.

Two Clocks and No Confidence

The two clock problem kills rewrites because there is no way to gain confidence in the new system.  Customers will see that the data has changed, but without an explanation there won’t be trust or confidence.

Finding the explanations requires finding and fixing all the differences.  Fixing bugs, differing definitions, and edge case logic until the two systems return the same result.

Finally, when your two clocks agree, then you are ready to release the rewrite.

Except by that point you don’t need the rewrite anymore.