Hi Richard,
You are right in principle, though it would take a long time to reverse engineer the rationale of some of the decisions in there (or really, what happens when those are removed).
In my head I'm just doing the rough calculation of doing this and it looks something like:
LOE = Med - High,
Risk of breakage = High
Expected cost of subsequent support fallout = High
Reward = Of all the things customers want..this isn't one of them (Probably none), However, combat technical debt (future reward...maybe...this area is pretty much never touched)
ROI summary = A slightly cleaner codebase in an area very few touch for which we probably expended lots of engineering dollars either coding it and/or fixing it. And while we are fixing it, having customers asking us why we did this?
Incentive = :(
Newer stuff we can do this with, because we are more test-driven these days and can pick up on how a small change broke some corner case (or perhaps everything) very quickly.
For the most part, we don't have those kinds of tests for the deep parts of the product that were written in 1996 and, in some cases, we no longer have the rationale for why things are the way they are.
That's why, in general, I'm more amenable to changing recent things and less for older things. There are exceptions some though.
- Seth