Most IDEs offer poor support for many common development tasks

According to numerous studies (Thomas Latoza has done many of them) developers spend most of their time either debugging code or determining the implications of a proposed change to code.

While today's debuggers have allowed us to be more sophisticated than sprinkling println statements throughout our code, it can still be difficult to debug code. Andy Ko (https://andyjko.com/) did some work to investigate why, even with advances in debugging tools, debugging is still difficult. He determined that one reason is that the debugger can only help the developer if they ask good questions about program behavior. If the developer runs out of good questions to ask, the debugger can't help them. Andy created a pretty cool debugger called Whyline (https://faculty.washington.edu/ajko/whyline-java.shtml) that allows a developer to point at the program output and then have the debugger help then ask and answer questions about the output.

Sadly it would appear though that there are no cool tools for investigating the implications of a change to code, even though this is an activity that most developers perform often and report significant difficulty with (see Thomas's recent paper at ICSE 2010). An analysis of programming tools published in Software Engineering suggests that there is a lack of tools that provide optimal support for activities that involve navigating multiple entities and relationships. Instead, development environments provide great support for navigating and viewing one entity at a time and one relationship at a time. But when you try to chain those together, as you typically do when investigating the implications of a proposed change, you're on your own.

There are many static and dynamic analysis tools that will help you figure out dependencies, hot paths etc. But when developers investigate a proposed change to code, it can be a very exploratory process. You may not know in advance the specific graph or data that will provide you the answer you need. Instead you use the available tools to gather a body of evidence that you then make sense of in your head. The more evidence you gather, the more your understanding of the problem space changes. The workflow typically goes something like:

• Pinpoint an existing method, class or some other type that might be affected by the proposed change
• Find references to that type
• Inspect the references and look for any that might be relevant in the context of the change proposed
• Follow each relevant reference
• Inspect various relationships for each reference (definition, callers, calls to etc)
• Continue in this way, following relevant paths through the code until a sufficient understanding has been built up

At each step along the way, your understanding of how the program works is changing. You might find something unexpected that you want to explore in more detail. You couldn't have predicted this beforehand so it would be difficult to use a tool that requires you to specify what components you want to view upfront. Instead, the whole process feels quite exploratory.

And it's hardly ever a linear process. You rarely go from component A to component B to component C. Instead, you typically go from component to component, following relationships that you think might be relevant. You will often go down some path, only to find after a few steps that it wasn't really relevant after all. So you backtrack to get back to where you forked off and follow a different relationship or navigate to a different entity. Instead of A -> B -> C it is more like A -> B -> X -> Y -> X -> B -> Z -> B -> C

According to the Software Engineering article, all the time your development tool is probably doing a great job of representing the current object you are investigating. But it probably doesn't do a great job of representing the path you have followed, the path you are on or the map that you are building. That stuff is probably all in your head or written down on paper.

The question I have is how well does this describe your own experience? Have you found any tools that you think really help in this context?

Comments

• Anonymous
  July 20, 2010
  Interesting Finds: July 21, 2010

• Anonymous
  July 25, 2010
  The comment has been removed