In general what’s typically missing in code is why certain code exists. This is very hard to capture without reasonably accurate coding standards and designs. Keeping roles and responsibilities highly consistent helps to keep the code in this state and doing this requires constant refactoring of even more recently written code. (Of course this is for projects whose lifeline is in the 5 – 10 year arena, which is crazy, but true for certain machine control applications)

And yes, I agree a big picture certainly does help see where code and complexity reign. If done correctly, this would happen when multiple interfaces must be integrated within a single class/entry point.

I’ve spent my entire career refactoring code that functions at ~75% case, but fails in a large set of other cases. Typically it is because these junction points are either poorly designed, written, or missing altogether. Not to belittle the idea of looking at something from 10,000 feet, but isn’t that what UML is all about?

rewrites can be of great benefit, if the relevant sections of the legacy code are recognized, documented and isolated.

Rewrites are necessary if the underlying technology changes significantly. Like porting an application from java to erlang(like we do right now).

Also, on an abtract level rewrite != rewrite, distinguishing different classes of “rewrites” is wortwhile.