Choosing a Boundary for a Legacy Pricing Engine
A retail platform has a 12-year-old pricing engine: a 9,000-line class that computes discounts, taxes, and promotions. It is called from 34 places. Two teams depend on it. Team A wants to add a loyalty-tier discount next quarter. Team B wants to replace the tax calculation with a vendor service. The engine has no tests. A staff engineer proposes a full rewrite behind a clean interface, estimated at 14 weeks. A tech lead proposes extracting only the tax calculation behind an interface first, estimated at 3 weeks, leaving the rest untouched. The product manager is worried about the 14-week estimate and asks which plan protects the loyalty-tier deadline.
1. Compare the two proposals as architectural decisions, focusing on what each one makes easy or hard.
Read the worked answer
The rewrite optimizes for a clean end state but concentrates risk: 14 weeks with no tests means the team cannot know it is behavior-preserving, and the loyalty-tier feature competes with the rewrite for the same people. It also front-loads a large irreversible commitment before the team has learned what the tax vendor actually needs.
The extraction optimizes for reversibility and learning. Putting an interface around tax creates a seam, gives the team a place to write characterization tests for at least that slice, and de-risks Team B's vendor swap. It does not help Team A directly - the discount logic stays in the monolith - but it does not block them either, because the loyalty feature can be added inside the existing engine while the seam work proceeds in parallel.
Key asymmetry: the 3-week option produces a reusable boundary and test scaffolding; the 14-week option produces the same boundary only at the end, and only if it succeeds.
2. The PM asks: which plan protects the loyalty-tier deadline? Answer with reasoning, not a preference.
Read the worked answer
The extraction plan protects the deadline better, but for a reason the PM should understand precisely: it does not shorten the loyalty work, it avoids coupling the loyalty work to an unproven 14-week bet. Under the rewrite, loyalty-tier discount code must either wait for the new engine or be written twice (once against the old, once against the new). Under extraction, loyalty work proceeds against a stable engine whose tax behavior is being isolated underneath.
The honest caveat: if the loyalty feature needs to compose with tax in new ways, the seam helps; if it is purely additive discount logic, the seam is neutral to the deadline and is justified by Team B's need and by test coverage. The recommendation should state that extraction is chosen for risk containment and parallel progress, not because it makes loyalty faster in isolation.
3. What would make you reverse this recommendation?
Read the worked answer
Name falsifiable triggers rather than vibes:
- If characterization tests around the tax slice reveal the engine's behavior is so entangled that no clean seam exists within, say, 5 weeks, the incremental plan loses its main advantage and a staged rewrite becomes more credible.
- If the loyalty-tier feature turns out to require changes to the same discount/tax interaction the seam is isolating, the two efforts collide and sequencing must be reconsidered.
- If the vendor's tax service contract is still undefined, extracting the seam now may lock in the wrong interface; in that case, defer the extraction until the contract is known and do characterization testing in the meantime. Stating these up front turns the decision into a reviewable one rather than a 14-week leap of faith.