Friday, June 20, 2008

Visualizing Development Sessions

Some interesting work has been going on in recording development sessions.

If you use Smalltalk, there is an interesting project,
Spyware, going on that allows you to visualize your development sessions. In addition, "Change Factory is a tool we are implementing which allows one to define a program transformation by first recording a concrete example of it."

I've been doing similar work focusing on C# and Visual Studio. Here is a visualization of one programmer's sessions over a period of few days:

Each pixel in the x-axis is one minute. The y-axis is the amount of activity. Blue pixels are navigation, and green pixels are edits.

Thursday, June 19, 2008

Stacking Visualization Results

Tools, like rule-checking systems, tend to generate a lot of output. Too much output to look at once, so we usually just sorting on something like severity and/or category to focus on the more interesting findings.

Another dimension that should be considered more often is grouping findings together based on other attributes. I would like to see more tools use a "gather and scatter" approach in collapsing results together. For example, I might want to gather all findings based on the corresponding class and browse the collapsed summaries.

I have been thinking about what a visualization would do to better support this concept. One interesting metaphor is creating "piles" or stacks. I have added this new feature to NosePrints to support gathering items as stacks. The biggest problem is giving more information about the other items in the pile. You could do things like averaging, but I think jitter might produce the best results. Maybe something like the Picasa photo collage would be interesting.

Visual Stacks

Saturday, June 14, 2008

Keeping out Bad Code

Our needs for keeping out bad code may be different, but finding the time and tools for supporting this process is still a challenge for many software projects.

There are some good tools that are helping:

For Java,
Find Bugs

For C#,

These tools fall short in different ways. Some tools act like the overly verbose, picky lint. This can be good your project is built from the ground up with an agreed set of rules to enforce. Rules are good for keeping out well-defined behavior, but not necessarily good at finding "funky" or bad-smelling code.

Other tools take a more 'screening' mindset. The tools have the sense that you might want to know how code quality metrics are changing over time and can be integrated with build processes such as maven or cruise control.

Almost none of the tools have been designed for doing a quick but comprehensive peer review. Crucible might be an exception.

Overall, these sets of tools tend to stick to a more conservative set of rules. Steps into code smell detection has seen timid, but has seen budding support in the tools. But as always, it is hard to define these as rules because the answer always ends up being "it depends".

My take for dealing with design problems has been with software visualization:

As part of my research, I have developed a tool that examines C# byte-code and produces mini-diagrams of source code that can be screened for design problems.