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 ObjectOrientedProgrammingLanguage''''''s which have a whole different set of abstractions to understand.

So a call to all of you
	*What is it that a MaintenanceProgrammer wants?  What would make understanding a ReallyLargeSystem easier for you?
	*What do you think would make large systems easy to understand?  Simple graph based views rapidly break down into a mess of lines and boxes.  How can we display a ReallyLargeSystem in an understandable manner?

AlistairHutton

CodeForTheMaintainer

Recommended Readings

* ''Reading Computer Programs: Instructor's Guide and Exercises'', http://www.deimel.org/comp_sci/em-3.pdf
* DiomidisSpinellis CodeReading: The Open Source Perspective ISBN: 0201799405
* Software Archeology, AndyHunt and DaveThomas. IEEE Software, 19(2):20-22
* Dunsmore, Alastair. Comprehension and Visualisation of Object-Oriented Code for Inspections (1998) http://citeseer.nj.nec.com/dunsmore98comprehension.html
* The section on maintenance in Chapter 2 of Facts and Fallacies of Software Engineering, by RobertGlass. ISBN: 0321117425
----
Excellent question:

* What is it that a MaintenanceProgrammer wants? What would make understanding a ReallyLargeSystem? easier for you? 

I want a tutorial.  Even better, I want all the code I read to be written as if it was a tutorial.  Sometimes this can't be done because of optimization, but we all know that's rare.  Most software can and should be as simple to understand as if it had been written to teach a novice how to write software just like this.

Another excellent question:

* What do you think would make large systems easy to understand? Simple graph based views rapidly break down into a mess of lines and boxes. How can we display a ReallyLargeSystem? in an understandable manner?

Unit tests help.  They don't help me understand the large scale structure, but they give me the confidence to modify the small scale structure until I do.
----
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.