We all know the EightyTwentyRule rule and we all know the how it applies to program creation and maintenance. 20% of the time spent creating, 80% spent maintaining. Of the maintenance time 20% is spent changing while 80% of the time is spent just trying to understand what the drugged up idiots who wrote the code in the first place meant to write.
The majority of time is spent reading code so why has there been so little effort and research put into tools that help program comprehension.
We're not talking about IDEs here, they are tools for writing the code in the first place, we're talking about something that helps you understand the hopeless mess that is a ReallyLargeSystem?.
From my initial reading in the field academic research is stuck with the problem of small scale, experiments are run with code reaching "gasp" a whole 1500 lines of code. As any MaintenanceProgrammer knows 1500 lines won't even get you through the front door. Furthermore these experiments and produced tools are based around Procedural Languages like C and Fortran, now large systems are being produced in ObjectOrientedProgrammingLanguages which have a whole different set of abstractions to understand.
So a call to all of you
Recommended Readings
Excellent question:
Another excellent question:
When I inherit a large codebase, one of the first things I do is run it through DoxyGen. The callgraphs and type dependency diagrams help a lot.
Also see TipsForReadingCode.