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.

It’s still in development, but it’s coming along quickly:

http://www.sublimetext.com/

Dunc

The source tree I primarily work on at work at the moment is roughly 150,000 lines of code - although metrics like that tend to de-value the actual content of the code. In our case, we’re dealing with a CMS written primarily in PHP and regular expressions with a lot of compacting done (read: each line is fairly complex).

I’ve done a similar comparison in the past where I took screen shots of code at an un-readable level. I took two screen shots: 1) before and 2) after. Sometimes a bird’s eye view is just what the doctor ordered.