advancedLegacy Code

Six Months To Rewrite The Claims Subsystem

Decide what you would do from the brief alone, including whether you would change anything at all. Everything below it is available, but the exercise stops working if you open it first.

The brief you were given

The claims-submission subsystem is nine years old, has almost no tests, and two of the three people who understood it have left. The team has budgeted six months to rewrite it against a written specification. You are asked to review the plan.

The trap — the fix that looks like good design and is not

Agreeing to the rewrite but adding a feature freeze on the old system so the target stops moving. It sounds like exactly the mitigation the plan is missing, it is easy to get agreement on at the start, and it is the thing that kills these projects. The business does not stop: within weeks the freeze is broken by something that cannot be deferred — a payer format change, a regulatory deadline — and now every such change must be made twice, in a system nobody wants to touch and in one that is not finished. The freeze also removes the only feedback the rewrite could have had, because for six months nothing new runs in front of a real claim.

Read this even if you are confident. It is here rather than behind a button because it is the answer most teams actually ship, it passes review, and the cost of it does not arrive until the change after this one.