|
|
| ||||||||||
I obtained my Ph.D. from the Software Practices Laboratory in the Department of Computer Science at the University of British Columbia, formerly supervised by Gail Murphy. I then worked for Carl Gutwin and Saul Greenberg at the the University of Saskatchewan's HCI Laboratory.
My interests lie in user-centred design, investigating problems affecting how computers support their users. I'm specifically looking at enhancing and assessing the support provided to programmers by their tools and environments to improve program understanding and exploration. My PhD research looked at improving the support for the types of questions that are asked by developers, and resulted in an Eclipse-based tool named Ferret. I'm also curious about the impacts of techniques like machine learning and visualization.
My favourite computer language is Smalltalk. Being a former OTIer, my flavour of choice is VisualAge for Smalltalk.
My primary responsibility at the UofS is to redevelop two networking toolkits designed to ease developing groupware applications.
DVCS, such as git, mercurial, and bazaar, have reached a sufficient level of maturity that they are being adopted by several major open- and closed-source projects. Why are developers switching? What do the projects see as the major benefit -- and downsides?
Conducting controlled experiments about programming activities often requires the use of multiple tasks of similar difficulty. In previously reported work about a controlled experiment investigating software exploration tools, we tried to select two change tasks of equivalent difficulty to be performed on a medium-sized code base. Despite careful effort in the selection and confirmation from our pilot subjects finding the two tasks to be of equivalent difficulty, the data from the experim ent suggest the subjects found one of the tasks more difficult than the other.
In this paper, we report on early work to create a metric to estimate the cognitive difficulty for a software change task. Such a metric wou ld help in comparing between studies of different tools, and in designing future studies. Our particular approach uses a graph-theoretic statistic to measure the complexity of the task solution by the connectedness of the solution elements. The metric predicts the perceived difficulty for the tasks of our experiment, but fails to predict the perceived difficulty for other tasks to a small program. We discuss these differences and suggest future approaches.
Programmers seek to answer questions as they investigate the functioning of a software system, such as "which execution path is being taken in this case?" Programmers attempt to answer these questions, which we call conceptual queries, using a variety of tools. Each type of tool typically highlights one kind of information about the system, such as static structural information or control-flow information. Unfortunately for the programmer, the tools seldom directly answer the programmer's conceptual queries. Instead, the programmer must piece together results from different tools to determine an answer to the initial query. At best, this process is time consuming and at worst, this process can lead to data overload and disorientation.
We present a model that supports the integration of different sources of information about a program. This model enables the results of concrete queries in separate tools to be brought together to directly answer many of a programmer's conceptual queries. In addition to presenting this model, we present a tool that implements the model, Ferret, demonstrate the range of conceptual queries supported by this tool, and present the results of several studies of the conceptual queries in use.
A variety of tools have been created to improve the effectiveness of such exploration. The usefulness of these tools has been argued largely on the basis of case studies, small narrowly-focussed experiments, or non-human-based experiments. In this paper, we report on a more rigorously controlled study of three specialized software exploration tools in which professional programmers used the tools to plan complex change tasks to a medium-sized code base. We found that the tools had little apparent effect; the effects observed instead appear to be dominated by individual styles and strategies of the programmers and characteristics of the tasks. In addition to presenting the results of the study, this paper introduces the use of two experimental evaluation aids: the NASA Task Load Index (TLX) for assessing task difficulty and distance profiles for assessing the degree to which programmers remain on-track.
Developers have reported becoming disoriented while exploring a software system, often manifesting as a feeling of lostness. We undertook an exploratory field study to investigate this phenomena in the context of software development, observing developers of the open-source Eclipse project for two hours each. The developers did report some instances of disorientation, but it was a rare occurrence; rather we observed strategies the developers used to remain oriented. We analyzed the data using the theory of visual momentum, identifying three factors that may lead to disorientation: the absence of connecting navigation context during program exploration, thrashing between displays to view necessary pieces of code, and the pursuit of sometimes unrelated subtasks.
My master's dissertation, under supervision by Gregor Kiczales, addressed the feasibility of building an aspect-oriented language and fully incremental implementation for Smalltalk, and resulted in a system named Apostle (Aspect Programming in Smalltalk). Apostle is to Smalltalk as AspectJ is to Java, except that Apostle supports the immediacy of the Smalltalk environment -- where there is no perceived compilation step! We condensed our findings into a technical report.
A class project resulted in the following paper, written with Mark Greenstreet. It shows that the performance of an asynchronous system is different from the expected `average-case', but rather is often determined by its slower operations. To optimize a system, it is important to test its sensistivity to its various operations and tune those that have the largest effect on overall system throughput.
I spent the summer of 2000 working with Stephan Gudmundson and Greg Smolyn, under the supervision of Gregor Kiczales, aspectifying some small- to medium-sized software projects as a proof-of-concept of AOP. We distilled some of our findings into:
You can find information on Aspect-Oriented Programming (AOP) at the Aspect-Oriented Software Development site.
In addition to being a computer hacker (in the good sense of the word), an avid reader, and hiker, I also like to travel and take photos. These travels are usually with my partner, Cheryl Wiramanaden (or see her research page), and sometimes even accompanied by our cats Abbey and Costa.
