Refactoring a Module Nobody Owns
A mid-sized company runs an internal billing service that has grown organically for six years. One module, which calculates proration when customers change plans mid-cycle, is about 4,000 lines long, has no automated tests, and is changed roughly twice a month. Each change requires about two days of manual verification by a finance analyst, and in the last year there have been three billing errors that reached customers, each requiring a credit and an apology. The engineer who wrote the module left two years ago. The team has a backlog of higher-visibility feature requests, and the engineering manager is reluctant to allocate time to the module because it does not appear on any roadmap. Two engineers have volunteered to improve it, but only part-time.
1. How would you make the case for investing in this module, and what evidence would you gather?
Read the worked answer
The case has to be made in the language the organisation already uses: money, risk, and delivery speed. I would gather three kinds of evidence. First, the cost of the current approach: two days of analyst time twice a month is roughly 48 analyst-days a year, plus the engineering time for manual verification, plus the cost of three customer credits and the support effort around them. Second, the risk: three customer-visible errors in a year on a module with no tests and no original author is a trend, not bad luck, and the next error could affect a larger customer or trigger a compliance issue. Third, the opportunity cost: every change takes two days longer than it should, which delays whatever feature depends on it.
I would also characterise the module itself so the estimate is credible. I would measure how often it changes, how large the changes are, and how much of the 4,000 lines is actually exercised by the twice-monthly changes. That tells us whether the whole module needs work or only a few hot spots. I would present the case as a small, time-boxed investment with a measurable return, not as a rewrite. For example, if characterisation tests around the proration rules cut manual verification from two days to half a day, the payback period is easy to calculate. The engineering manager is more likely to approve a bounded investment with a visible return than an open-ended refactor, and the evidence makes the trade-off explicit rather than a matter of taste.
2. The manager approves only a part-time effort by two engineers. What would you do first, and how would you keep the work from stalling?
Read the worked answer
With part-time effort the main risk is that the work stalls and leaves the module half-changed, which is worse than untouched. So the first step is to pin down behaviour, not to restructure code. I would have the two engineers write characterisation tests around the proration rules as they currently behave, using real historical cases including the three that caused errors. Those tests are valuable even if the code is never refactored, because they turn the analyst's two days of manual verification into an automated check. I would also write down the rules in plain language and have the finance analyst confirm them, which surfaces the undocumented assumptions that caused past errors.
To keep the work from stalling I would make it small and continuous. I would break the effort into short, independently useful increments, each of which leaves the module in a working state, and attach each increment to a real change that was going to happen anyway. That way the work rides along with demand rather than competing with it. I would also set a simple visible metric, such as manual verification time per change, and report it monthly so the manager can see the return. If the part-time effort does stall, the tests and the written rules remain, so the investment is not lost. I would avoid a big-bang rewrite entirely, because a part-time team cannot safely carry a long-lived branch of a billing module.