recent discoveries

The engineering director at my last workplace used to hold weekly “iteration reviews” with his teams, which was really just a fancy title for a meeting to communicate what you’ve discovered during the past week. Building software is a lot about making discoveries but the same could really be said about any creative process, including developing a research program. This past week I’ve been mostly doing meta-thinking about my research, which has helped me to discover some high-level things about my work.

what is software project visualization?

I’ve been calling my research topic “software project visualization” (SPV) so far. SPV is really about using techniques in information visualization to put a software project history into pictures. It’s both exploratory and analytic.

SPV is exploratory in the sense that it allows stakeholders to explore events and artifacts that make up a project history. It’s analytic in the sense that it allows stakeholders to make informed decisions by presenting statistics and summaries of a project history.

who cares?

There has been prior work in software engineering that points to the importance of project history in introducing newcomers and guiding changes in a project. In the wild, software project histories consist of an eclectic collection of structured and unstructured data contained in multiple different repositories. If we can integrate project artifacts of all types in visual representations of a project history, maybe we can make it easier for stakeholders to find the information they need to complete their tasks and make more informed decisions.

what are the research questions?

There are many research angles to take on SPV and I haven’t decided yet on the angle that offers the best balance between interestingness and finishing my degree quickly. Here are some questions I’ve thought of so far:

One simple question: is SPV easy to use? This is an easy study to set up and execute, but it will lead to the least interesting results. In the best case, I’ll find that my tools are indeed easy to use in the confines of a usability lab, which doesn’t have much to do with the context-rich environments that software projects take place in. Also, having users work with project data that has no meaning to them isn’t all that valuable.

How do stakeholders use SPV with their own projects? Analyzing how users interact with my tools would indicate what pieces of the tool are most popular and might reveal some usability problems, but offers no insight into how useful the tools really are. This is a much more expensive study than the previous.

What do stakeholders discover about their own projects using SPV? This is the question I really want to ask, but it’s a big one so I need to pick a manageable chunk out of here and I’m still not sure what that is.