One reason this happens, that I've observed, is risk avoidance. If you're working in a mission-critical code path, every line of code has been battle-tested th

One reason this happens, that I've observed, is risk avoidance. If you're working in a mission-critical code path, every line of code has been battle-tested through {m,b,tr}illions of executions over many years. You better have a damn good reason to change it, and if you do, you better be damn sure it works. You can preach about {unit,functional,integration,load,performance} tests, but tests can only verify a miniscule sliver of the state space of any non-trivial program. So in that situation, engineers tend to avoid risky changes and to accrete stuff instead. I haven't been convinced that it's unreasonable, either.