日本ソフトウェア科学会第 32 回大会 (2015 年度) 講演論文集

Unravel Programming Sessions with THRESHER:
Identifying Coherent and Complete Sets ofFine-granular Source Code Changes
Stephanie Platz, Marcel Taeumel, Bastian Steinert,
Robert Hirschfeld, and Hidehiko Masuhara
Development teams benet from version control systems, which manage shared access to code repositories and persist entire project histories for analysis or recovery. Such systems will be ecient if developers
commit coherent and complete change sets. These best practices, however, are dicult to follow because
multiple activities often interleave without notice and existing tools impede unraveling changes before committing them. We propose an interactive, graphical tool, called

Thresher, that employs adaptable scripts to

support developers to group and commit changesespecially for ne-granular change tracking where numerous changes are logged even in short programming sessions. We implemented our tool in Squeak/Smalltalk
and derived a foundation of scripts from ve refactoring sessions. We evaluated those scripts' precision andrecall, which indicate a reduced manual eort because developers can focus on project-specic adjustments.
Having such an interactive approach, they can easily intervene to accurately reconstruct activities and thus
follow best practices.

patterns [3].

1 Introduction

Software evolution induces very high costs in

Software developers benet from version controlvcss), which manage collaborative work

systems (software development [2] and hence developers areadvised to follow best practices to maximize theand persist whole project histories. In systems such
†1 and Mercurial,†2 developers can
as Gitbenets of vcss. One important practice is continuous integration [7]: commit and test code onchanged source code with descriptive messages intoa regular basis.

commitWhen committing, only store

distinct branches to separate features or bug xes.

small, coherent, complete change sets with a brief

When committing, branching, or merging, new ver-yet descriptive message to improve comprehensibil-sions of the project arise and a particular devel-

ity [29]. A well-organized project history can also

opment trace emerges in the

improve code review processes [1] and recommendervcs. Such historicalinformation can then be used to ease code compre-

systems [4]. Robbes et al. [22] observed that de-hension [31] or to reason about software evolution

velopers frequently commit once per working day
on average.

Further research ( [14] [16] [22]), how-incoherent change sets. Buse and Weimar [5] also foundever, shows that developers tend to commit

完全かつ一貫した細粒度コード変更集合の検出によりプロ
グラミングセッションを解きほぐす THRESHER
Stephanie Platz, Marcel Taeumel, Bastian Steinert,
and Robert Hirschfeld, Hasso Plattner Institute,
University of Potsdam, Germany.

増原英彦, 東京工業大学 数理・計算科学専攻, Departmentthat only two-thirds of commits get assigned with
an descriptive message.
We argue that one challenge for developers isthat multiple activities interleave [18]often with-of Mathematical and Computing Sciences, Tokyoout being noticed even in short sessions as illus-

Institute of Technology.

trated in Figure 1. Manual refactorings, for exam-†1 http://git-scm.com†2 http://mercurial.selenic.com

ple, typically include changes to aected code that
get accidentally postponed because developers sim-long to the same activity. Based on a lab study [27]including 5 programming sessions with up to 250
ne-granular changes each, we derived a foundationof scripts that can be combined to automatically reveal activity-specic change sets. When evaluated,groupsrec-a script assigns changes into
and adds†3 if changes are already part of dis-ommendations

tinct groups. After this scriptable analysis, developers can explore all proposed groups, adjust them
manually, or resolve recommendations. We imple-

Fig. 1 Multiple activities (A to E) often
interleave without notice (top) and bestpractices suggest to untangle and assemblechanges before committing them (bottom).
This is often challenging with existing tools.

Threshermented the graphical toolin Squeak/S†4 which visualizes intermediate results
malltalk,
concisely and reduces the eort for manual adjustments. The underlying rules of identifying coherent
and complete sets of changes can easily be accessed
and modied.
In this paper, we make the following contribu-

ply forgot.

Existing tool support typically poses

high eort on following best practices, especiallytions:•A design for an interactive, scriptable tool weThresher, which supports developers tofor ne-granular change models that track numer-call

ous changes even in short sessions [27]. Developers

assemble coherent and complete change sets fortend to explain all tangled and scattered changes
from one session in asingle commit messageifne-granular source code changes•

A description of an exemplary scripting in-any. Consequently, understanding project histories

terface, which supports the Squeak/Smalltalk

will be impeded. Based on these observations, wechange model, to emphasize the simplicity ofaddress the following research question:
How can we support developers to identify

extending•Thresher for domain-specic needs

A brief description of scripts we extracted fromcoherent and complete sets of ne-granulara lab study to support Smalltalk-based refacto-changes when committing code to a repos-

ring sessionsincluding an evaluation in terms

itory?

of precision (almost 100%) and recall (33% toWe dene a change set as

coherent if it contains

57%) of the proposed groups, which illustrates
coherence over completeness

only changes that origin from a single activity; it iscomplete if it contains all changes from that (com-

The next Section 2 summarizes related work.

pleted) activity. We focus on ne-granular change

Section 3 describes existing challenges in state-of-models where every modication to the code basethe-art commit tool support.

is tracked, even two consecutive changes that re-present our toolscind each other.

tion to its scripting capabilities; we also present a

We think that semi-automatic

In Section 4, weThresher and give an introduc-

coherent sets over com-

foundation of scripts for developers to get started.

false-negatives. Then, developers do only have tolimitations and applicability to other environments.

merge change sets to make them complete. In fact,

Section 6 sketches hypotheses and next steps for

we believe that there cannot be one fully automatic

this kind of commit tool support. Finally, we con-approach but the developer has to be part of theclude our thoughts in Section 7.

tool support should favor

plete ones, that is, avoid false-positives but accept

We evaluate those scripts in Section 5 and discuss

process to benet from tacit project knowledge.
We propose a scriptable, interactive, graphical†3

tool that supports developers to (1) identify conse-engineering.

cutive changes that indicate continuity of an activity and (2) collect scattered runs of changes that be-

Note that we use the term recommendation unrelated to recommendation systems in software

†4

The

Squeak/Smalltalk

ment: www.squeak.org

programming

environ-industrial setting. Robbes et al. ( [23] [24]) also track

2 Related Work

timestamps and use time-coupling to improve re-

We are not aware of projects that try to pro-call.

Besides that, they track tool window usage,

actively involve developers in the process of com-code authors, and annotations to indicate auto-

mittingmanymated refactorings. If actually noticed, the devel-

projects that investigate how to automate the iden-

oper can express the beginning of a new activitytication of coherent change setsonly after com-

explicitly. Yoon et al. [33] log all low-level events

mits have been taken place. Some projects deriveof the Eclipse code editor in an XML format to berules by mining project histories, other projects

processed by other tools. 

create rules for changes that have detailed con-ne-granular change tracking without making as-

text information. Most of them deal with domain-

sumptions about the level of detail that is tracked.

specic characteristics, which emphasizes the needFor example in our Squeak/Smalltalk environment,of adaptability and manual intervention when using

there were logs for tool-controlled refactoring ac-

in such tools.

tivities, which later simplied script code. Having

changes.

There

are,

however,Thresher promotes

When mining repositories, existing changes are

this, other extensions to the change model could

often modeled and analyzed at a xed level offurther improve both scripts, results, and hence thedetail.

overall utility.

Herzig and Zeller ( [13] [14]) applied ma-chine learning to adjust project-specic weights or

Working with numerous ne-granular changes

thresholds for data dependencies, lexical distanceraises challenges for graphical tools from an infor-

measures, or test impact couplings. They analyzed

mation visualization perspective. Many approaches

coherent change sets that were already assigned toapply a timeline metaphor to provide overview

particular bug xes. Kawrykow and Robillard [16]and details on demand as pluggable visualizations

looked for behavior-preserving thus non-essential

in programming environments.

changes, which include rename-refactorings. They

Azurite [34] and CodeTimeline [20].  We argue

claim that such changes aect coherence nega-that common list, table, or tree views are capable

tively.

Kim and Notkin [17] derived logical rulesof presenting huge amounts of data in a support-

from change sets, which also identify anomalies

ive way. Problems will arise primarily if developers

and hence tangling changes such as All meth-

have no simple means to congure the views' level

ods X in classes that implement interface Y got

of detail.

deleted,ing developers that required conguration support

except class Z. This should also help de-scribe commit messages.

 We derived a foun-dation of scripts from 5 programming sessions,which arguably reect many important characteristics of object-oriented projects in Smalltalk. One
can easily extend this approach with mining some
Squeak/Smalltalk repositories to identify more corner cases. As scripts represent concise and accessible descriptions of a particular change model, we
argue that developers can easily adapt those scripts
to accommodate domain or project-specic needs.
Whenapproaches

are

open

to

extensions

inthe change model, identication and classication
methods can benet from any kind of context information such as developer activity tracking. For
example, Coman and Sillitti [6] tracked tool interactions and created the notion oftime intervals ofintensive access to help detect activity switches;
Zou and Godfrey [35] veried this approach in an

Examples include

Thresher employs those means by giv-in terms of adaptable scripts with direct feedback
after script modications.

3 Challenges in Existing Tools
In this section, we highlight important factorsthat substantiate the need for better tool support when committing source code to avcs. We

cover the nature of interleaving programming activities, state-of-the-art tool support, and specicsof the Squeak/Smalltalk change modelas we built

Thresher in that programming environment.

3. 1 Interleaving Programming Activities
The more programming activities interleave during a session, the more important it is to untangle them to commit only coherent and completechange sets. The number of actually traceable activities will be inuenced by the developer's task

Fig. 2 Usually, commit tools show changes in long, scrollable lists, which developers have tountangle by tedious manual selection for each single commit. LTR: Monticello for Squeak(http://www.squeak.org), TortoiseSVN (http://tortoisesvn.net), SourceTree(http://www.sourcetreeapp.com)
working mode frees them from being too specicand the level of change tracking editing tools pro-avide. As for the task, a simple bugx may spawn

too early in highly uncertain scenarios like many re-

only one activity but drive-by corrections andsearch projects face. At the end of such a session,other activities interleave quite often ( [18] [21])

developers have numerous changes to untangle. We

those should be documented in separate commits.

argue that there is a need for better commit tool

As for the change tracking, the more editing events

support to even promote explorative programming

get tracked, the higher the chance that a devel-and still ease comprehension of and learning fromoper's activity drifts get documented for the longproject histories.

termall the more if there are many modications
that rescind each other during a session.

3. 2 Interactive Commit Tool Support

File-based environments (such as Java + Eclipse

Figure 2 gives an impression of how existing com-

+ Git) compare the local working copy with the

mit tools make use of graphics and interaction.

latest version in theFirst and foremost, those tools present changes in

vcs to determine changes atthe level of text lines, which typically match pro-scrollable lists with support for manual selection

gram statements.

only.

as

We consider such an approachcoarse-grained because overwritten changes areAdvanced ltering covers presets such asall, none, and invert selection. It doesn't matter

not tracked as coherent program entities but only

whether changes are le, method, or line-based:at the level of character ranges.

Object-based

Such interfaces do not support untangling manyenvironments+changes very well. Furthermore, multiple activities

CoExist(such

as

SmalltalkSqueak+[26]) log any modication to the code

have to be considered one after another.

base by means of method and class changes. This

However, we do consider lists or tables as ap-

allows for rewinding or replaying single decisions

propriate views because they can visualize chrono-

and whole programming sessions.

logical order in a compact fashion. What existingmodel is more

Such a change

ne-grained and persists more de-tails of a project's history.
There is a programming approach called

explo-

rative programming [8], where developers are en-tools miss is a way to lter and group changes according to some rules, which may not be expressedwith a single button-click but rather simple scripts.
Additionally when seeing a complete and coherent

couraged to make any change as they go withoutchange set, developers may be better suited to pro-having a specic task in mind. They do not know

vide a descriptive commit message.

upfront whether they will x some bugs or add
some neat features or clean-up some code.

Such3. 3 The Squeak Change Modelof the user interface and the internal tool logic. It

Squeak has a direct notion of changes, change†5les, and change sets but all in a local sense andis implemented in Squeak/Smalltalk and builds on

not shared like common

rect manipulation of all graphical objects.

vcss such as Git. Tracked

top of the Morphic framework, which supports diHav-

changes include any source code modication af-

ing this, the developer can easily nd responsible

fecting classes, methods, and their categories.

In

data transformation scripts starting from a visual

Squeak, change sets represent means to manually

impression and express modications in the scriptorganize changes to easily le-out and share them,source code.

for example, via mailing lists. There is a tool calledstraction, the framework can update all running

tween sets in case the developer forgot to switch

ming environment and a tool building framework.

before starting her activity.

Building tools means composing widgets and writ-

Change Sorter, which supports moving changes beHaving this, Squeak

provides a local history of everything that happensin the programming environment. However, not all

Due to this simple yet powerful ab-

tools consistently. Thus,

Vivide is both a program-ing script code.
The underlying concept ofVivide, that is de-changes are reversible per se but, at the least, they

scribing tools as data processing pipelines, ts to

can be replayed.

our idea of congurable and combinable analysisThe

vcs called

Smalltalk community has a†6 and an in-image tool called

SqueakSource
Monticello as counterpart (left in Figure 2). When com-stages for grouping changes. Developers open it after nishing a programming session to assemble recent changes into groups, add descriptive messages,

mitting changes, Monticello only sees the latest ver-and eventually commit them to thesions of classes and methods. Cherry-picking is sup-a few clicks.

ported at the level of methodsnot lines or rangesof text.

4 Thresher
In this section, we explain structure and use of

We make use of a recent research project called

CoExistvcs with only

Squeak'schangeprocessed with scripts.

model by storing data to revert changes.

It alsorives from the fact that we want to identify alladds the capability to Monticello to store ne-changes that belong to a certain activity and ig-

granular changes in SqueakSource such as two con-nore the rest (for now)just like the agricultural

secutive modications of the same method. In thatmachine does withsense,

[26],

which

extends

our tool as well as details about how changes are

CoExist elevates the ne-granular but local

change tracking of Squeak to the level of Monticello/SqueakSource, which is now comparable to othervcss.

Having this, we createdThresher for Squeak/S-

The name thresher de-winnowing.

4. 1 Changes, Groups, and Recommendations
The overall goal is to make developers commit coherent and complete change sets with a descriptive

coherent if itmalltalk but are arguably able to transfer our nd-message. We classify a change set as

ings to other programming languages, tools, andcontains only changes that origin from a single ac-

environments.

tivity; it iscomplete if it contains all changes fromThresher, scripts

3. 4 The Vivide Tool Building Frameworkthat (completed) activity.

We implemented our toolwith the†7 tool building framework [28]. Vivide pro-often not be achieved on a scripting level because

VivideThreshervides a direct mapping between all graphical parts†5

Except for this section, we do not use the termInsupport to detect activity continuations and thusgrouping changes coherently. Completeness mightsome developer knowledge might be hard to express
or even ambiguous.

Then, manual grouping via

Thresher's graphical interface will take place.

There are multiple scripts that modularize thechange set in a Squeak-specic way but in achange analysis process in a sequence of stages. At

broader sense throughout this paper.

the rst stage, each change has its own group as-†6 http://www.squeaksource.com†7 https://github.com/hpi-swa/vivide

suming that each change belongs to its own pro-d/remove/reorder) them as well as reviewing(or debugging) their eects.
There are several tasks that the developer accomplishes when working withThresher. Those de-scribe a seamless workow and should encourage tofollow best practices by committing only coherent,
complete change sets as well as adding descriptive
messages.
At rst, the freshly opened

Thresher window

analyzes recent changes with the existing scripts
to form groups and add recommendations.

Fig. 3 Thresher works bottom-up: groups ofchanges will be merged (1-3) according toscriptable rules. There are no partial merges(4) but recommendations (5a) to be resolved
manually by the developer.
gramming activity. Intermediate stages either ex-Thesource view À lists all changes chronologically witha distinct label. The result view Á shows all resulting groups, which contain these changes and maybe†8 ones. At the top of that view,
several ungroupeddiscarded changes are listed such as recognized de-bugging code. All groups get monogram labels foreasier recognition. At this point, the di view Â is
not used because no group is selected.

pand those groups by merging them or propose rec-After that, the developer reviews all group's con-ommendations to be resolved manually. In the lasttents to verify coherence and completeness. Select-stage, each resulting group is meant to be com-

ing a group in the result view Á will reveal moremitted to thedetails in the di view and highlight the contents,

vcs. The concept is illustrated in

Figure 3.
In script code, programmers can iterate over all

which are automatically selected in the source view.
Any group can be marked as

ready-to-commit bychanges, check for specic properties, and assign

clicking the checkbox near the group name.

matches to new groups.

This

Those checks depend on

will separate that group visually by moving it to

the information available; a stage may also add new

the top as shown in Figure 4 for the group bug x:

information to changes by integrating external data

less than key.

sources. For example, results of static or dynamic
code analysis can be embedded this way.

Group C contains 6 changes and 4 recommendations, which are highlighted in blue and orange.
To see the content of single changes, the developer

4. 2 The Graphical Interface

Thresher's graphical user interface is shown in

Figure 4. It consists of four main views:

À

Sources View shows a chronologically or-dered list with all recent changes.

The order

can be adapted.

ÁResult View shows resulting groups and rec-ÃTo discard the changes, the developer selects themand drag-drops them onto the Discarded Changes
group.
Recommendations can either be single changes
or whole groups as proposed by previous stages.
When hovering over a recommendation, the reason

ommendations. Developers can resolve recom-

is shown in a tooltip (Figure 4, bottom right). The

mendations with button clicks, change groups

developer can accept recommendations by clicking

via drag-and-drop, and add descriptive mes-

the tick-icon next to it; the cross-icon rejects it.

sages.

Âcan hover over one of them in the source view.

Di View shows details about all selected

After resolving all recommendations, the developer can merge groups if she discovers a more ap-

groups to support developers to revise their de-propriate intent. This happens by simply drag-and-cisions in detail.

drop groups on top of each other. It is also possi-

Stages View reveals intermediate results of

the involved scripts, supports adapting (ad-†8With ungrouped or single changes we mean
single-change groups.

Fig. 4 The main views of Thresher: À local, uncommitted changes, Á computed change setswith recommendations, and Â detailed source code dis.
ble to move selected changes (or groups) between

with a grouper as argument.

groups.

no return value but can trigger side eects via the

Finally after reviewing a group, the developer
can propose a descriptive name, which is displayed
as the group's name to help identify complete
ones.

When she decides to commit, name anddescription are used ascommit message. Besides

That function has

grouper's interface, that is, creating and adding
groups of changes.
If there are already existing groups, developers
can inspect their contents and consider them. At
the beginning, there are as many groups as there

manual naming, a short description of structural

are changes.

changes is appended automatically such as addedchange's current group is fetched and the nested

class SWA18World and modied method Player >>structure of groups (Figure 3) is extended.

render:.

following snippet extends the example above:

Developers can accommodate domain or projectspecic needs by adding, removing, or reordering
Each stage has a current script, whichdevelopers can access, modify, and re-execute to
update the results.
(Figure 5 resp.

Once visible, theThe"..." [:change |4. 3 Scripting and Stages View
stages.

For each match in a script, thatstages view

Ã in Figure 4) shows intermediatechange property = 'SomeFilter' ifTrue: [group add: ((grouper groupOf: change) -> 'Reason for
addition.')]]. "..."
To write eective scripts,

developers need toknow about possible change properties and thegrouping results. Scripts access the change model

scripting language to write scripts.

and create groups with the help of a grouper likehave the conciseness and expressiveness of thethis:Smalltalk language and are only limited by the en-[:grouper | |newGroup|
newGroup := CustomGroup new.
grouper allChanges do: [:change | "See below."].
grouper addGroup: newGroup.
].
In our implementation, the scripting language is
Smalltalk and scripts are just blocks evaluated with
thegrouper instance automatically.

Each script

is like an anonymous function that will be called

Here, lters

vironment's loaded libraries. In particular, external
data sources may also be queried and their answers
used in such expressions. For example, one might
think of a library that supports connecting email
accounts with source code and hence reveal further information about the original author of thechanged piece of code.

Thresher's scripting capabilities can be summa-

rized like this:Scripts are high-level descriptions

Thresherof change characteristics and create or merge appro-

signed to groups in preceding stages,

priatewill handle conict resolution and may add recom-

groups while using a grouper for navigation.

Dierentgroup classes represent distinct change

characteristics with an optional

pivot change for

identication. Initially, each change is in a singlechange group. Arbitrary changes can be put into acustom group. Groups are unit of reuse inAscripts.

grouper supports navigating changes in the cur-mendations because changes can only have a single
group. Developers do not have to deal with conict
handling when writing scripts.
Scripts can also modify existing groups that werecreated by previous stages.

By default, scripts

do not modify previous decisions but

add, merge,

rent group hierarchy and manages top-levelor recommend new changes from emerging groups.

across all

For example, two groups of the same kind suchgroupsscripts. It is not meant to be extended.

Recommendations are created automatically ifchanges are associated with two distinct groups.

To present a more elaborate example, the following script analyzes changes for method additions/removals and combines them with all othermethod changes that update corresponding mes-

as MethodAddOrRemoveGroup are usually merged andnot added as sub-groups.

those groups are meant to be committed.

4. 4 A Foundation of Scripts
We implemented a set of complementary scripts

sage sends:[:grouper |grouper allChanges
select: [:change | change
isMethodAddOrRemove]
thenDo: [:pivot | | group |group := MethodAddOrRemoveGroup new.
group add: ((grouper groupOf: pivot) -> pivot name).
grouper methodChanges do: [:change |"1) Check for removed methods."

pivot isRemoval &(change isSendRemoved: pivot) ifTrue: [group add: ((grouper groupOf: change)-> ('Send removed:', pivot
selector)].
"2) Check for added methods."

pivot isAddition &(change isSendAdded: pivot) ifTrue: [group add: ((grouper groupOf: change)-> ('Send added:', pivot
selector)]].

that aim for detecting most characteristics as extracted from several programming sessions [27]. In
most cases, they use structural/code change information but they may also consider chronologicalanity.

model and hence serve as a valid baseline forother projects in the Squeak/Smalltalk environment. Due to space constraints we cannot print all
scripts' details here but will only summarize theirintents:1.

associations, which attach a textual description as reason to each change, are used to llcan benet from such contextual explanations.

If they were already as-

Refactoring grouping All changes thatgrouped.

Depends in respective hints being

present in the change data.
3.

Renaming grouping Detects a manual or

tool-driven renaming of a source code artifact
and groups it with all consecutive changes ofthe same kind. Aects also renamed variables.
4.

Organizing grouping All consecutive changes

that reorganize software artifacts are grouped.
This includes class categories and method protocols.
5.

Added/removed-method grouping The

addition or removal of a method is groupedWith only 19 lines of Smalltalk code, the devel-

just create new groups.

consecutive†9 arewere triggered by tool-driven refactorings arewith all changes that update the respective

oper can automate such an untangling of changes.
If existing changes are ungrouped, the grouper willAllgrouped.
2.

Developers do not have toprovide reasons but debugging unexpected results

Consecutive groupingchanges on the same source code artifactgrouper addGroup: group]].
Here,

Having this, they encode the Smalltalk

language characteristics besides Squeak's change"Add new group to hierarchy."groups with changes.

Eventually, top-levelgroups are important for the developer because†9Source code artifacts can be packages, classes, or
methods.

message sends in the source code.

Appliesstatic analysis to locate all sends.

Added/removed-variable grouping The

6.

addition or removal of an instance/class variable is grouped with all changes that update
the respective references in the source code.

itive eects of the Vivide programming environment, in which Thresher runs. This, however,remains subject to further research.

5. 1 Analyzing Programming Sessions
Our

proposed

scripts

are

based

on

sampleAdded/removed-class grouping The ad-data, which Steinert et al. collected during a lab

dition or removal of a class is grouped with all

study [27] with 22 developers that had the task tochanges that concern this class' methods, vari-improve source code of a game in 2-hour sessions.

ables, and references.

The number of changes range from 40 to 250 per

7.

The last three stages add recommendations:session.

8.

activities, which included debugging, refactoring,

Close-to-artifact recommendation Single

changes arerecommended to groups whosechanges aect the same artifact.

Considerschronological anity.

Close-to-polymorphism recommendation

9.

Single changes arerecommended to groups thatconcern method additions/removals but are
ambiguous due to polymorphism.

ConsidersPretty-print recommendation

changes of cosmetic nature are

and code clean-up. Having this, we derived several
scripts that should automate this mapping processcoherent groups of consecutive changes
assemble scatteredchange runs. Reconsider Figure 1 for the distincin terms ofand which can be combined totion of tangled and scattered changes.
In particular, we chose 5 out of the 22 sessions
as representatives because their changes contained

chronological anity.
10.

We manually mapped those changes toSinglerecommended

many refactorings or frequently interrupted activities with much tangling and many revisions; someto groups whose changes aect the same arti-of them contained at least one larger refactoring.

fact if chronological anity is high. If there is

We reviewed each ne-grained change

no such group, those changes are merged into a

and added it to coherent, complete sets to get kind

new group. Such changes include modicationof aof whitespace or comments, renaming of tem-created their own commits with Monticello, whichporal variables, or cascading message sends.

we only partially took into account because at that

Having this, the scripts do not detect activity

time, it forced them to commit all changes at once.

switches but rather describe continuations. Frommanually

gold standard for our analysis. Some developers

We did not interview the developers but were fa-

one stage to another, scripts merge existing groups

miliar with the domain of the game and its sourceof changes into bigger ones.

code. Eventually, we identied recurring character-

Therefore, the or-der of scripts can inuence the results.

For now,

Thresher should stop processing if further merg-

istics that indicate strong relationships or obvious
activity switches as summarized in Table 1.

We

th data set to simulate a programminging might decrease coherence of groups. Splittingused the 6

up groups in scripts and hence describe activity

session whose contents were not explicitly used toswitches would be a valuable addition to our con-derive those scripts.

cept and is considered future work.

5 Evaluation of Scripts
In this section, we evaluate the accuracy of thebasic scripts inThresher, which we derived froma programming study [27].

We then estimate themanual eort that remains to complete the mapping of all changes to their activitiesby interacting with the tool's graphical interface.

We have not yet evaluated to overall utility ofThresher. To some extent, we rely on the pos-

5. 2 Method
We quantify the accuracy ofThresher's basic

scripts as well as the manual eort that is necessary to get an ideal result.
For the accuracy, we compare the expected set of
related changes with the calculated one. Let the expected groups be AE = {3, 5, 6} and BE = {1, 2, 4}
where digits indicate a change's running number.

= {3, 5}, BC ={6}, and CC = {1, 2, 4}. The expected set of rela-

Let the calculated groups be AC

Fig. 5 The stages view in Thresher supports exploring intermediate results and adapting thescripts.

Characteristics

Data sets

Programming breaks between dierent refactorings (activity switch)

I II

Changed statements for debugging output or breakpoints (to be ignored)

I

Consecutive changes in the same artifact

I II III IV V

IV
VConsecutive renamings of artifacts including updates of their uses in the code

IV

Consecutive reorganization of methods' protocols

I

Changes of methods in dierent classes with shared protocol

I

Similar patterns in identiers of artifacts

V VI
III

V VI

II III IV

VI

Added/removed a method and update their uses

I II III IV V VI

Added/removed an instance/class variable and update their uses

I

Added a class and initial methods/variables as well as initial uses

I

Removed a class and update their uses

I II IIIIV V VI
VI
V VI

Table 1 Characteristics that rendered data sets interesting for deriving a foundation of scripts inThresher.
tions would be

E = {{1, 2}, {1, 4}, {2, 4}, {3, 5}, {3, 6}, {5, 6}}
and the calculated one would be

C = {{1, 2}, {1, 4}, {2, 4}, {3, 5}}precision is now dened as P = |E ∩ C| / |C| and recall

tity, as known from the domain of information retrieval [30]. In this example, precision is 1.0 (100%)and recall is 0.67 (67%), which indicates thatallcalculated groups are coherent but manual review-by expanding the groups into pair sets. The

ing and merging is required for completion.

as R = |E ∩ C| / |E|. Both describe the accuracy ofdevelopers either are directly able to assign changes

our scripts' results, respectively quality and quan-to activities after reviewing them once (minFor the manual eort, we think of two extremes:=

2·nchanges ), or they have to look through all changes
for each activity again (max = nactivities · nchanges ).

cision of 100% and a recall of 25% for session VI,

When using

ther adaptation needed. The developer does only

Thresher, this eort is reduced be-

however, indicate a satisfying result without fur-cause it depends on the number of proposed groups

have to assemble the proposed groups with the help

instead of single changes.

of recommendations and manual drag-and-drop in-

The developer clicks

to accept/reject single recommendations or all at
once. Drag-and-drop interactions can merge groups
or single changes.

teractions.

5. 4 Discussion and Threats to Validity
After the manual analysis of all changes, we con-Thresher's scripts cannot run fully

5. 3 Resultsrmed that

We got a precision of 96% to 100% for our ve

automated but developers have to intervene.

Ondata sets as summarized in Table 2. Having this, wethe one hand, several decisions rely on the de-met our goal of avoiding false-positives in groups byveloper's insights in the particular domain andfavoring coherence over completeness in the scripts.

project, which were

The upper part in the table shows information

number ofchanges and number of expected groups. The midabout the session size by means of

not materialized in the change

data. On the other hand, our scripts may not correctly reect the characteristics found.

Althoughwe cross-checked several characteristics among us,

dle part shows the accuracy as described above. It

there was not always consensus.

includes the number of calculated groups that

there were several method extractions across theexactly match the expected commits and the number

For example,

code base and one of us argued to combine themrefactoring group but another one would
domain-specic informationof recommendations that should help reduce man-into aual eort. The lower part approximates the manual

rather consider moreeort including the minimal amount of click/drag-and split them apart. We found similar conclusions

and-dropin [6] [10] [25].

actions in the user interface.

Thresher is well suited to interac-

The recall indicates that 33% to 57% of the re-tively help developers to decide which particularlations, which express activity continuation, werecharacteristics to pursue and when to merge pro-detected by our scripts. For the data set V, we sim-

posed groups.

ply adapted the script to increase recall; we expect

We derived the scripts and tool requirements

developers to do the same when facing many small

fromgroups. Regarding the number of groups compared

we found an arguably representative spectrum of

only

5

programming

sessions.

Althoughto the expected commits, an expected commit ischange characteristics for the Squeak/Smalltalk

roughly spread over two to three groups.

Since

programming environment, other sessions may con-some commits were completely detected (see #tain more special cases. As dierent kinds of activi-

Exact Matches), other commits are spread overties inuence the number and structure of changes,

more than three groups.

we should analyze more sessions that do not mainly

We explicitly counted the number of manual ac-

deal with refactorings and bug xing but also with

tions; this number can be approximated as two

feature implementations like classied by Hattori

times the number of expected commits because thiset al. [11]. Those could reveal further characteris-corresponds to the distribution of commits overtics [23] [32] such as more additions and less modi-

proposed groups.

cations of methods.

For some data sets this is even

less, which means that the given recommendations

The concept of recommendations accounts forhelp reduce manual eort. Notice that the devel-

scripts' interdependence; it helps developers ad-

oper could also accept or reject

just the proposed groups before committing them.

all recommenda-

tions for a particular group with a single click.
Programming session VI was analyzed to give arst impression of the quality and reusability ofThresher's base scripts. We extracted patterns

However, misleading recommendations may negatively

aect

the

coherenceofachangeset.

Thresher can miss to recommend the actually correct group; we have no means to prevent that.

from sessions I to V, which had to be adapted to

Our scripts detect activity continuations rather

consider several corner cases in session V. A pre-than switches and thus related changes rather than

Data set

I

II

III

IV

V

V*

Number of Changes

121

57

39

74

157

157

211

Number of Expected Groups

8

5

6

7

4

4

4

Number of Calculated Groups

20

10

7

12

58

34

40

Number of Exact Matches

1

3

4

1

1

1

0

Number of Recommendations

20

4

2

21

32

31

22

Precision (%)

96

100

100

100

100

100

100

Recall (%)

35

43

57

35

1

33

25

Minimum Interactions

242

114

78

148

314

422

40

20

14

24

116

48

968

285

234

518

628

-

844

160

50

42

84

232

96

160

Ratio (%)

17

18

18

16

37

15

19

Number of Manual Merge Actions

16

6

4

14

-

16

31

Accuracy

Eort
with

ThresherMaximum Interactions
withThresherVI

80

Table 2 Evaluation results comparing manual analysis (expected groups) with the scripts ofThresher (calculated groups). [* Scripts adapted for V due to low recall]which is undecid-

also dier from the one used in the programmingable [13]. This may be contrary to how developers

environment, which was not the case in Squeak/S-

would manually select coherent change sets from amalltalk.

checking for unrelatedness;chronologically ordered list of recent changes. Ad-

6 Hypotheses and Future Workditionally, our scripts do not cope withBasedsuccessive

activities but would merge them into a single one.
For example, the developer may rename methods asa refactoring (A) and then use those to implement
a new feature (B succeeding A).

ourexperiencewith

implementing

Thresher in Squeak/Smalltalk and providing afoundation of scripts based on the lab study [27],
we derive the following hypotheses:•

We reduced the implementation and computa-

Given a foundation of scripts that considers a particular programming language and its

static analysis of the methods' source code to add useful infortion eort of the scripts by prepending achange model, developers will rarely have toadapt those scripts except for project-specicmation such as changed references, variables, andmessage sends. When implementing such a tool in aonneeds.

•

If developers are knowledgeable about thedierent environment, the benets of such caching

scripting capabilities in such a commit tool,

depends on the existing change model.

they are more likely to improve their personal

Our scripts only detect low-level relations between changes.

Future work should include more

abstract characteristics such as design patterns [9]as previously investigated by[15] [19].

Dynamic

analysis could also reveal interesting relations by,forexample,collecting

concrete

type

informa-tion [12] to be used in scripts.
Applicability to other object-oriented languages

workow by taking advantage of that.

•If developers adapt such scripts for projectspecic needs, they will make fewer mistakes
and save time during the commit process.

Besides running experiments to test those hypotheses, we are eager to improve the general ideaof how ne-granular changes might be combined
into coherent and complete groups. In addition tocontinuity of activities between

is straightforward because the concept of classes

describing on theand methods is reected in many of our scripts.

changes, we think that it is important to also split

Languages with fundamentally dierent concepts,

up bigger groups to indicate

such as logic programming, may reveal quite dif-thus separate commits. Finally, expressing rules offerent characteristics. The scripting language may

activity switches anddependency relationships in scripts is valuable so†10 andthat the correct commit order of change sets cannancial support of HPI's Research School

be ensured, too.

the Hasso Plattner Design Thinking Research Pro†11
gram.

Furthermore, we want to try out visualizations
based on structures other than lists, tables, ortrees. For example, recommendations across group

References

boundaries might be better displayed with a graph[ 1 ]similar to Figure 3.

Finally, we have to general-ize our scripting approach to other programming
systems and their change models. File-based models, for example, may reveal dierent traits thanobject-based ones.
For all these improvements, we see a need for datafrom programming sessions that go beyond simple
refactoring tasks such as adding features or xing
bugs. Only then, we can establish a useful scriptinginterface to support programmers to accommodate
project-specic requirements.

composition of code review changesets. Proceedingof the 37rd International Conference on Software
Engineering (ICSE), ACM/IEEE, 2015.
[ 2 ] B. W. Boehm. The high cost of software. Practical Strategies for Developing Large Software Systems, pages 315, 1975.
[ 3 ] S. A. Bohner and R. S. Arnold. Software Change
Impact Analysis. John Wiley & Sons, 1996.
[ 4 ]We presented

Thresher, a scriptable, interac-

tive, graphical tool that developers can use after programming sessions to identify coherent andcomplete sets of ne-granular changes to be committed to avcs. A foundation of scripts automat-

ically detects related changes that indicate activity continuations; developers then manually assemble those scattered groups into complete activity
descriptions.

In

IEEE/ACM, 2010.
[ 6 ]I. D. Coman and A. Sillitti. Automated identi-Proceedings of the 16th IEEE International Conference on
Program Comprehension (ICPC), pages 212217.
cation of tasks in development sessions. In

IEEE, 2008.

P. M. Duvall, S. Matyas, and A. Glover. Continuous integration: Improving software quality andreducing risk. Pearson Education, 2007.

[ 7 ]

In

We showed that our foundation of scripts propose

Automat-Proceedings of the 25th International Conference on Automated Software Engineering (ASE), pages 3342.

[ 8 ]in code or change structures.

R. P. L. Buse and W. R. Weimer.

ically documenting program changes.

We argue that it is very important

project and its domain that cannot be manifested

Changes, evolution,

agement. In Recommendation systems in software
engineering, pages 477509. Springer, 2014.

to involve the actual developer into this process
because there is much tacit knowledge about the

M. Borg and P. Runeson.

and bugs: Recommendation systems for issue man-

[ 5 ]7 Conclusion

M. Barnett, C. Bird, J. Brunet, and S. K. Lahiri.

Helping developers help themselves: Automatic de-

R. P. Gabriel. I Throw Itching Powder at Tulips.

Proceedings of Onward! Essays. ACM, 2014 (tobe published).
[ 9 ]E. Gamma, R. Helm, R. Johnson, and J. Vlis-

Design patterns: Elements of reusable objectoriented software. Pearson Education, 1994.
sides.

[10]

N. Gold and A. Mohan.

A framework for un-groups with a precision of almost 100% indicating

derstanding conceptual changes in evolving sourcethat developers can rely on their coherence and fo-

code. Incus on adjusting their completeness with respect toan activity. We argue that such tool support promotes the usage of ne-granular changes, which isbenecial for explorative programming strategies
omitting explicit checkpointsand detailed tracking of project histories.

Acknowledgments
We wish to thank Jens Lincke, Lena Herscheid,

Proceedings of the 19th International Conference on Software Maintenance (ICSM), pages
431439. IEEE, 2003.
[11]

L.

P.

HattoriandM.

Lanza.

On

the

na-

Proceedings of the 23rd International Conference on Automated Software Engineering Workshops, pages 6371, 2008.
ture of commits.

[12]

M. Haupt,

M. Perscheid,

and R. Hirschfeld.

Type harvesting: A practical approach to obtaining
typing information in dynamic programming lan-

Proceedings of the 2011 Symposium on
Applied Computing (SAC), pages 12821289. ACM,
guages. In
2011.

Lysann Schlegel, Mark Rooney, Marko Röder, andPhilipp Tessenow for fruitful discussions and valuable feedback.

We gratefully acknowledge the -†10 www.hpi.uni-potsdam.de/research_school†11 www.hpi.de/en/research/design-thinking-research-program[13]K. Herzig and A. Zeller.

Untangling changes.

Unpublished manuscript, September, 2011. http://

www.st.cs.uni-saarland.de/publications/files/
herzig-tmp-2011.pdf, accessed: July 1, 2014.

[14]

K. Herzig and A. Zeller. The impact of tangled

Proceedings of the 10th International Workshop on Mining Software Repositories(MSR), pages 121130. IEEE, 2013.
code changes. In

[15]

D.

Heuzeroth,

T.

Holl,

G.

Hogstrom,

andW. Lowe. Automatic design pattern detection. In

Proceedings of the 11th International Workshop on
Program Comprehension (IWPC), pages 94103.
IEEE, 2003.
[16]

D. Kawrykow and M. P. Robillard. Non-essential

Proceedings of the
33rd International Conference on Software Engineering (ICSE), page 351, ACM/IEEE, 2011.

changes in version histories. In[17]

M. Kim and D. Notkin. Discovering and repre-

Proceedings ofthe 31st International Conference on Software Engineering (ICSE), pages 309319. IEEE, 2009.
senting systematic code changes. In[18]

A. J. Ko, R. DeLine, and G. Venolia.

Infor-

mation Needs in Collocated Software Development
In Proceedings of the 29th International
Conference on Software Engineering (ICSE), pages
Teams.

344353. ACM/IEEE, 2007.
[19]

C. Kramer and L. Prechelt.

Design recovery

by automated search for structural design patterns

In Proceedings of the
3rd Working Conference on Reverse Engineering(WCRE), pages 208215. IEEE, 1996.
in object-oriented software.

[20]

A. Kuhn and M. Stocker.

CodeTimeline: Sto-

International
Conference on Software Engineering (ICSE), pages
rytelling with Versioning Data.

In

13331336. IEEE/ACM, 2012.
[21]

A. Meyer, T. Fritz, G. C. Murphy, and T. Zim-

mermann. Software Developersâ Perceptions of
Productivity.
[22]

SIGSOFT FSE, ACM, 2014.

Electronic Notes in

Theoretical Computer Science, 166:93109, 2007.
[23]

R. Robbes and M. Lanza.

Characterizing andProceedingsof the 15th International Conference on Program
Comprehension (ICPC). IEEE, 2007.
understanding development sessions. In[24]

R. Robbes, D. Pollet, and M. Lanza.

Logicalcoupling based on ne-grained change information.

Proceedings of the 15th Working Conference on
Reverse Engineering (WCRE), pages 4246. IEEE,
In

2008.
[25]

How eective developers investigate source

An exploratory study. IEEE Transactions
on Software Engineering, 30(12):889903, 2004.
code:
[26]

B.

Steinert,

D.

Cassou,andR.

Hirschfeld.

CoExist: Overcoming aversion to change - Preserving immediate access to source code and run-time

Proceedings of the 8th Symposium on Dynamic languages (DLS), pages 107118. ACM, 2012.
information of previous development states. In[27]

B. Steinert and R. Hirschfeld.

How to com-pare performance in program design activities: ToIn Design Thinking Research: Understanding Innovation, pages 219238. Springer, 2014.
wards an empirical evaluation of CoExist.

[28]

M.

Taeumel,M.

Perscheid,

B.

Steinert,

J. Lincke, and R. Hirschfeld. Interleaving of Modication and Use in Data-driven Tool Development.

In Proceedings of the ACM Symposium for New
Ideas, New Paradigms, and Reections on Everything to do with Programming and Software (Onward!), pages 185200. ACM, 2014.
[29]

Y.

Tao,

Y.

Dang,

T.

Xie,

D.

Zhang,

and

S. Kim. How do software engineers understand code

Proceedings of the ACM SIGSOFT 20th International
Symposium on the Foundations of Software Engineering, page 51. ACM, 2012.
[30] C. J. van Rijsbergen. Information retrieval (second edition). Butterworths, 1979.
changes?: An exploratory study in industry. In[31]

A. von Mayrhauser and A. M. Vans.

Programcomprehension during software maintenance andevolution.
[32]

Computer (IEEE), 28(8):4455, 1995.

B. J. Williams and J. C. Carver. Characterizing

software architecture changes: A systematic review.

Information and Software Technology, 52(1):3151,
2010.
[33]

Y. S. Yoon and B. A. Myers.

Capturing andAnalyzing Low-Level Events from the Code Ed-

R. Robbes and M. Lanza. A change-based ap-

proach to software evolution.

phy.

M. P. Robillard, W. Coelho, and G. C. Mur-

In International Workshop on Evaluationand Usability of Programming Languages and Tools(PLATEAU), pages 2530, 2011.
itor.

[34]

Y. S. Yoon, B. A. Myers, and S. Koo.

Vi-

sualization of Fine-grained Code Change History.

In Proceedings of the 2013 IEEE Symposium on
Visual Languages and Human-centric Computing(VL/HCC), pages 119126. IEEE, 2013.
[35]

L. Zou and M. W. Godfrey. An industrial casestudy of Coman's automated task detection algorithm:

What worked, what didn't, and why.

In

Proceedings of the 28th International Conference on
Software Maintenance (ICSM), pages 614. IEEE,
2012.