Deep Intellisense

Deep Intellisense is a Visual Studio 2008 plugin that surfaces information from various silos (source control, bug tracking, mailing lists, etc.) to provide developers with instant context-sensitive feedback on any source code they are reading in the editor. Deep Intellisense works with Visual Studio Team Foundation System projects (such as those hosted on CodePlex), email archives (from Outlook) and Sharepoint sites.

Use Deep Intellisense to...

• Find the best person to talk to
• Learn about the history of unfamiliar code
• Understand the bugs afflicting a method
• Discover what other people are doing to your code
• Figure out which checkins fix which bugs
• See if someone's changes could cause regressions

Deep Intellisense was designed and created by Andrew Begel and Reid Holmes in the Human Interactions in Programming group at Microsoft Research. Its base infrastructure uses the Bridge database, by Gina Venolia.

For more information, please contact Andrew Begel.

Deep Intellisense is based on the Bridge, a graph of developers and their activities like source code checkins, bug database entries, and mailing list messages where each entry is linked to another when there is a relationship between them. For example, a source code checkin was authored by a particular developer. A tester opened a bug report. A user emailed a stack trace from a crash to the recipients of a mailing list. Deep Intellisense presents a code-centric view of this graph: for any code entity (class, method, field, property) that you click on, it shows the related checkins, bugs, mailing list messages, and people discovered through transitive two hop graph traversals.

Deep Intellisense presents three views: Current Item, Event History, and Related People.

<Screen shot of Current Item View>

The current item view shows the current code entity that is selected in the Visual Studio editor. It summarizes the checkin, bug and discussion forum messages that are related to the particular code entity. If you clicked on a method call, or use of a class or variable, Deep Intellisense may have trouble recognizing exactly what the fully qualified name of the entity is (Deep Intellisense works at a parse-level, but performs no semantic analysis). In this case, it will show a pulldown menu to let you pick from a set of alternatives. A button allows you to search for this symbol in MSDN.

<Screen shot of Event History View>

The event history view shows a sorted list of bugs, checkins and discussion forum messages that we have discovered are related to the selected code. By clicking on the bug title, change set, or message title, you can bring up further information. If you click on the associated person's name, you can email them to ask them a question. This view also allows you to dynamically filter the entries you see using a word wheel, and lets you sort the entries by date, person and event type.

<Screen shot of Related People View>

The related people view pulls out all of the people related to the code and lists them in alphabetical order. It shows the number of bugs, checkins and forum messages each of them has created about the particular code that is selected. In addition, you can click on a person's name to send him an email with a question. There is a little social tagging in Deep Intellisense: if you like a person's checkins or messages and want everyone to pay attention to them, clicking on the green thumbs-up icon will attach the icon to all events by that person in the event history view. If the person is irrelevant to your code investigation, clicking on the red thumbs-down icon will hide their corresponding events from the event history view. To see these hidden events again (and turn off the red thumbs-down icon), click the Show All button in the related people or event history view.

We built Deep Intellisense to address a number of research findings:

1. Locating high-level code-related information is very important. Developers frequently want access to design-level information, but find that it is difficult to locate (Ko, DeLine, Venolia 2007)
2. Developers rely heavily on implicit knowledge. For example, while a bug and a checkin may both be useful, the implicit link between them (perhaps the bug was fixed by the checkin) is most important. (La Toza, Venolia, DeLine, 2006).
3. Developers search through bug and checkin history on a daily basis in some large companies in the Pacific Northwest.

Contextual Inquiry

We interviewed 3 developers and 2 testers to better understand how they performed their daily tasks. We focused on specific tools and techniques that enabled them to get their jobs done.

• Tester #1: Hotfix tester. Is given a bug and a diff by a developer. As such he knows exactly what was changed and who to talk to.
• Tester #2: Performance tester. Investigates a lot of code to figure out where to put tracing markers.
• Developer #1: Dev lead. Spends 70% of his time looking at code written by other developers. Lots of source code control command-line work.
• Developer #2: 50% of time is reading code. Lots of bug database searching, works hard to find the diffs associated with a bug.
• Developer #3: Team is mostly new but working on an older product. Specifics of a change aren’t interesting but knowing there has been one is.

During these interviews several common themes emerged between the SDETs and the SDEs:

• "What happened most recently?" Recency was a recurring trend in the comments, both developers and tersters wanted to consider the information available to them in reverse-chronological order.
• "Who should I contact about this?" If, after looking through bug and change history, the developer decided to follow up with someone from an external team identifying the correct contact person was important. Who they talked to depended on the type of information they wanted: it could be the person who closed the bug, opened it, made a comment in it, made the check-in, or created the spec associated with the code.
• "How can I filter the information available to me" Both testers and developers had an overabundance of information available to them. They wanted to filter first to find that information that is relevant to the code they are investigating and then filter further to find information that is relevant to the aspect of the code they are considering. Providing a flexible way to access the information they required was very important.

Interestingly, we also found two pieces of information that was not interesting to either group:

• Burstiness: There was little interesting the density of changes. For example, if there were 4 check-ins in two days and nothing until 2 months later, that was not an interesting fact developers cared about.
• Relationship to product schedule: While the strict ordering of events (this check-in before that one, or this bug opened before that check-in was made) was interesting, how these events related to the product schedule (e.g., was this check-in before milestone 3?) was not interesting to these developers.

In addition to the commonalities between developers and testers, we also found that they had some role-specific qualities:

• Developers investigate a large amount source code they did not write themselves.
  • Frequently try to infer how a bug relates to a check-in (or vice versa). This is similar to the point in the background material about the value of inferred information. By relating a bug to a check-in the developer can see both what was changed (from the diff in the check-in) and get some idea as to why it was changed (by looking at the associated bug).
  • Developers are often trying to answer "Am I wrong or are they?" By this, the developer is trying to determine if external code is behaving the way it should (and they should fix their own code) or if they need to contact the owner of the external code to have them make a change to their code.
• Testers work on tasks for specific people.
  • Testers are often assigned a bug, and given a diff, by a specific developer. From this they have an explicit point of contact for any questions. At the same time, they are still interested in seeing if the bug they are testing (or its associated check-in) is related to any other similar bugs and check-ins for a particular piece of code.
  • Testers spend a lot of time looking at particular details in bugs and investigating specific diffs (to determine what exactly needs to be tested).

Prototype Development

After interviewing each developer about their work practice, we provided them with a series of low-fidelity mockups of Deep Intellisense. The intent of this exercise was to focus our development effort on providing information that is relevant to developers and testers, in a format that is usable to them, as they undertake their daily activities. After seeing how they responded to the mockups, we settled on three main design goals for Deep Intellisense:

1. Provide context-relevant historical code information.
2. Work with the developer's existing environment.
3. Link directly to tools developers are familiar with.

By context-relevant we mean that instead of always providing file-level granularity for a particular change, Deep Intellisense should provide listings of only those changes that affected the class, field, or method of interest. We chose to work within the developer's current environment because developers already have an overwhelming number of independent tools at their fingertips; we didn't want to exacerbate this situation. We chose not to try to replicate existing tools (notably source code control, bug database and diff tools) as developers are already familiar with these; instead we focused on making interactions with these tools more effective.

Reid Holmes, Andrew Begel. Deep Intellisense: A Tool for Rehydrating Evaporated Information. In the 5th Working Conference on Mining Software Repositories (MSR), Leipzig, Germany. May 2008. [pdf]

Gina Venolia. Textual Allusions to Artifacts in Software-related Repositories. In the 3rd Working Conference on Mining Software Repositories (MSR), Shanghai, China, May 2006. [pdf]

Developer Awareness Tools

1. Anita Sarma, Zahra Noroozi, Andre van der Hoek. Palantir: Raising Awareness among Configuration Management Workspaces. In the Proceedings of the 25th International Conference on Software Engineering. Portland, Oregon. May 2003.
2. Biehl, J. T., Czerwinski, M., Smith, G., and Robertson, G. G.  FASTDash: a visual dashboard for fostering awareness in software teams. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. San Jose, California. April 2007.
3. Holmes, R. and Walker, R. J. 2008. Promoting developer-specific awareness. In Proceedings of the 2008 international Workshop on Cooperative and Human Aspects of Software Engineering. Leipzig, Germany, May 2008.
4. Cheng, L., Hupfer, S., Ross, S., and Patterson, J.  Jazzing up Eclipse with collaborative tools. In Proceedings of the 2003 OOPSLA Workshop on Eclipse Technology Exchange. Anaheim, California, October 2003.
5. Damian, D., Izquierdo, L., Singer, J., and Kwan, I.  Awareness in the Wild: Why Communication Breakdowns Occur. In Proceedings of the international Conference on Global Software Engineering. Washington, DC. August 2007.
6. Gutwin, C., Penner, R., and Schneider, K.  Group awareness in distributed software development. In Proceedings of the 2004 ACM Conference on Computer Supported Cooperative Work. Chicago, Illinois, November 2004.
7. de Souza, C. R., Quirk, S., Trainer, E., and Redmiles, D. F. Supporting collaborative software development through the visualization of socio-technical dependencies. In Proceedings of the 2007 international ACM Conference on Supporting Group Work. Sanibel Island, Florida, November 2007.

Mining Software Repositories

1. Cubranic, D., Singer, J., and Booth, K. S. Hipikat: A Project Memory for Software Development. IEEE Trans. Softw. Eng. 31, 6. June 2005.
2. Śliwerski, J., Zimmermann, T., and Zeller, A. HATARI: raising risk awareness. In Proceedings of the 10th European Software Engineering Conference Held Jointly with 13th ACM SIGSOFT international Symposium on Foundations of Software Engineering. Lisbon, Portugal, September 2005.