Discussion questions from CS 7390 lecture

Date: 1/26/96

Presented by: John Stasko (in place of Jeremy)

Topic: Program Visualization 2

• In Seesoft, what if the code (functions) were coloured by how many times they were called - to help show which functions should have the most effort spent optimizing them?
• Authors of Seesoft say you can use colouring to observe how the number of bug fixes in a file is high in files where many programmers have touched (figures 9 and 10). You can also use those figures to find files touched mostly by one programmer with many bug fixes. This can possibly indicate the ability of a programmer. Discuss the implications.
• Where else could the Seesoft techniques be usefully applied?
  • where else do you find data sets that large: reference books, WWW pages, databases
  • how would you apply Seesoft techniques to WWW pages: one pixel line per page, pages grouped by site, use of color, etc?
• Seesoft is restricted by the screen width. Big projects, especially object- oriented programming tend to have many files, although they are not necessarily very long. It may be useful to have a scrollable window for the display. But then that defies the purpose to have a big picture of the whole thing. One solution may be to allow files to move around. eg. when related modification is highlighted, those files that have the modification are clustered together.
• Seesoft makes use of "brushing" in selecting which column to make active, or which colours on the colour scale to display. But, in most applications it tkaes a mouse click to initiate an action. In the case where a continuous change needs to be demonstrated by movement of a pointing device the user must usually hold down a button. What advantage does "brushing" really give to this system, if any?
• The Seesoft display shows approximately 900 lines of code per column and approximately 25 columns (files) at a time for a total of maybe 20k lines of code. The authors state that the processing limits of the telephone switching network or guidance control system can have "millions" of lines of code however. How would one scale up a system like Seesoft to support such an environment and would it be useful to developers, maintainers, managers, etc. for such complex systems?
• By default, Seesoft will display the coloured statistics for a file complete with indentations shown. While it looks neat, is there any real use for showing hte indentation structure? Can any useful information be gained from this display, especially since the effect is that of looking at a printout of the code from a "long" ways away?
• Seesoft seems like an impressive tool that is especially useful for large scale programs with documented changes and the like. How useful could it be for smaller programming projects where documentation for changes is scarce? Can a set of hooks gather this information automatically? Also, a zoomable interface between the character/ixel and the full size text would be useful.
• Are low resolution systems (line-oriented) useful for quick analysis of the code? Is there a possibility of information explosion?
• With respect to Seesoft, who is the targeted audience? I don't see how a programmer would find this useful is he/she wrote this code.
• It obviously takes a lot of information to get anything useful out of Seesoft. What sort of techniques are used to gather all of this information? It must comd from many different sources, each with a different output format. Could it be made general?
• Adding dynamic information to Seesoft would aid in visualization. What if you could see in red the lines that were executed most often? What other stats could this be combined with to get new info?

• PV, like FIELD, presents a large amount of information in a visual representation. A presentation of this much information can be overwhelming in any form it appears. What can be done to reduce the expected culture shock of initially learning about these systems? Would example pieces of data be intuitive (for teaching what to look for in different views) or is each case too different for generic example solutions?
• What, if any, are the relationship between the various Process windows/views? (tree, Colorstrip, and textual output) It seems like the other windows are well integrated so these must be too, but the paper didn't really describe how?
• Although Figure 2 in PV is black and white, the text descirbes the display as being in colour, and describes how each individual Colorstrip window has it's colours bound to some feature. In addition, the only feature that differentiates the ColorStrip windows is the title on the window border. Is it possible to use more than one ColorStrip display at the same time and still have the colours be meaningful?
• Like the authors of many other systems, these authors present only small examples of their own use of their software to solve solve problems. In addition, their system appears to stand apart from any development tools. How might such a system to incorporated into a development environment to assist developers to avoid identified mistakes (e.g. the multiple start up files problem) rather than finding them through post hoc analysis?
• Does PV have any relevance to any programs outside of huge industrial parallel applications? It seems that this tool provides a great deal of information at the price of clarity of the data which would be most useful, namely program statistics, to many software development efforts.
• PV is a good performance analsysis tool. But a human is needed to recognize the pattern and produce analysis. There are so many aspects of the program being displayed; it's very hard for users to get any useful information out at the first glance. It will be useful to compile the raw data and display them in a more meaningful way.