How we envision using Development Assistant (DA):
We would like to use the tool for a variety of tasks, outlined below. The fact that DA is centered on graphic output is essential, because I think textual output does not synthesize the architecture or the complexity as well as pictures.
- Clean up of code prior to extension
Very often in legacy code, we are faced with the need to add functionality to an existing system or sub-system. The code has often evolved over years, in the hands of several developers. Usually the current set of features has to be maintained, because the entire corporation is used to it (sales force, manual writers, marketing, hot lines). In this case the extraction of the design with DA is extremely useful to understand the current system. Usually some preliminary work is performed with the new functionality in mind, but without expanding the
functionality renaming of symbol, redistribution of code in subroutines, change of passed parameters to increase flexibility, redistribution into more files). At each step, the progress can be monitored by the developer using the DA. Finally, on the consolidated base, the new feature can be added, in complete harmony with the old ones. Again these additions can be monitored rapidly with the DA.
- Preparing code reviews
The call trees allow a rapid architectural introduction for the people who have to review the code. Code reviews are often hindered by the fact that the reviewers ask structural questions before they can effectively review the code at the line level.
- Introduction of new developers
Often developers other than the original authors of the code need to work on a piece of code, either for fixing bugs of for extensions. The preliminary study of the code can be supported by the graphs in a very efficient way. In this mode the developer work interactively, zooms in, zooms out, masks, unmasks, groups and colors function and data structures while building his mental model of the machine. Occasionally he or she will print a copy for later references.
- Explanation to non-developers and management
The entire software development process tends to be a black box to non-developers. It is my experience that a graphic tool shows more clearly the complexity of the system to the public and helps outlining the issues. In the areas where the graphs show lack of structure and the Kiwiats are alarmingly red, even non-programmers will understand the need for investments. After the work, the graphs can show the difference and the increase in quality. When big work is needed, the pictures can show the breadth and depth of the work and help in securing the necessary resources to properly do the work. |
