Unravel Programming Sessions with THRESHER: Identifying …€¦ · Unravel Programming Sessions...

Sanshusha pLATEX2ε: c01_taeumel : 2017/1/16(17:14)

103

Unravel Programming Sessions with THRESHER:Identifying Coherent and Complete Sets ofFine-granular Source Code Changes

Marcel Taeumel, Stephanie Platz, Bastian Steinert,

Robert Hirschfeld, and Hidehiko MasuharaDevelopment teams benefit from version control systems, which manage shared access to code reposito-

ries and persist entire project histories for analysis or recovery. Such systems will be efficient if developerscommit coherent and complete change sets. These best practices, however, are difficult to follow becausemultiple activities often interleave without notice and existing tools impede unraveling changes before com-mitting them. We propose an interactive, graphical tool, called Thresher, that employs adaptable scripts tosupport developers to group and commit changes—especially for fine-granular change tracking where numer-ous changes are logged even in short programming sessions. We implemented our tool in Squeak/Smalltalkand derived a foundation of scripts from five refactoring sessions. We evaluated those scripts’ precision andrecall, which indicate a reduced manual effort because developers can focus on project-specific adjustments.Having such an interactive approach, they can easily intervene to accurately reconstruct activities and thusfollow best practices.

1 IntroductionSoftware developers benefit from version control

systems (vcss), which manage collaborative workand persist whole project histories. In systems suchas Git†1 and Mercurial,†2 developers can commitchanged source code with descriptive messages intodistinct branches to separate features or bug fixes.When committing, branching, or merging, new ver-sions of the project arise and a particular devel-opment trace emerges in the vcs. Such historicalinformation can then be used to ease code compre-

完全かつ一貫した細粒度コード変更集合の検出によりプログラミングセッションを解きほぐす THRESHER

Marcel Taeumel, Stephanie Platz, Bastian Steinert,and Robert Hirschfeld, Hasso Plattner Institute,University of Potsdam, Germany.増原英彦, 東京工業大学情報理工学院, Department of

Mathematical and Computing Science, Tokyo Insti-tute of Technology.コンピュータソフトウェア,Vol.34,No.1 (2017),pp.103–118.[研究論文] 2016 年 3 月 24 日受付.†1 http://git-scm.com†2 http://mercurial.selenic.com

hension [37] or to reason about software evolutionpatterns [3].

Software evolution induces very high costs insoftware development [2] and hence developers areadvised to follow best practices to maximize thebenefits of vcss. One important practice is con-tinuous integration [8]: commit and test code ona regular basis. When committing, only storesmall, coherent, complete change sets with a briefyet descriptive message to improve comprehensibil-ity [35]. A well-organized project history can alsoimprove code review processes [1] and recommendersystems [4]. —Robbes et al. [26] observed that de-velopers frequently commit once per working dayon average. Further research [16] [18] [26], however,shows that developers tend to commit incoherentchange sets. Buse and Weimar [5] also found thatonly two-thirds of commits get assigned with a de-scriptive message.

We argue that one challenge for developers isthat multiple activities interleave [21]—often with-out being noticed even in short sessions as illus-trated in Figure 1. Manual refactorings, for exam-ple, typically include changes to affected code that


104 コンピュータソフトウェア

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

get accidentally postponed because developers sim-ply forgot. Existing tool support typically poseshigh effort on following best practices, especiallyfor fine-granular change models that track numer-ous changes even in short sessions [33]. Developerstend to explain all tangled and scattered changesfrom one session in a single commit message—ifany. Consequently, understanding project historieswill be impeded. Based on these observations, weaddress the following research question:

How can we support developers to identifycoherent and complete sets of fine-granularchanges when committing code to a repos-itory?

We define a change set as coherent if it containsonly changes that origin from a single activity; it iscomplete if it contains all changes from that (com-pleted) activity. We focus on fine-granular changemodels where every modification to the code baseis tracked, even two consecutive changes that re-scind each other. We think that semi-automatictool support should favor coherent sets over com-plete ones, that is, avoid false-positives but acceptfalse-negatives. Then, developers do only have tomerge change sets to make them complete. In fact,we believe that there cannot be one fully automaticapproach but the developer has to be part of theprocess to benefit from tacit project knowledge.

We propose a scriptable, interactive, graphicaltool that supports developers to (1) identify conse-cutive changes that indicate continuity of an activ-ity and (2) collect scattered runs of changes that

belong to the same activity. We make use of a sim-ple scripting language as a flexible extension mecha-nism, because we think that software projects havedomain-specific characteristics to be specified bythe who are developers actually working on theproject. Our scripts are basically just Smalltalkcode:

[:grouper |

"Add all moved methods in a group."

grouper addGroup: grouper

moveMethodChanges].

Based on a lab study [33] including 5 program-ming sessions with up to 250 fine-granular changeseach, we derived a foundation of scripts that canbe combined to semi-automatically reveal activity-specific change sets. When evaluated, a scriptassigns changes into groups and adds recommen-dations†3 if changes are already part of distinctgroups. After this scriptable analysis, develop-ers can explore all proposed groups, adjust themmanually, or resolve recommendations. We imple-mented the graphical tool Thresher in Squeak/S-malltalk,†4 which visualizes intermediate resultsconcisely and reduces the effort for manual adjust-ments. The underlying rules of identifying coherentand complete sets of changes can easily be accessedand modified.

In this paper, we make the following contribu-tions:• A design for an interactive, scriptable tool we

call Thresher, which supports developers toassemble coherent and complete change sets forfine-granular source code changes

• A description of an exemplary scripting in-terface, which supports the Squeak/Smalltalkchange model, to emphasize the simplicity ofextending Thresher for domain-specific needs

• A brief description of scripts we extracted froma lab study to support Smalltalk-based refacto-ring sessions—including an evaluation in termsof precision (almost 100%) and recall (33% to57%) of the proposed groups, which illustratescoherence over completeness

The next Section 2 summarizes related work.

†3 Note that we use the term “recommendation” un-related to the domain of recommendation systems.

†4 The Squeak/Smalltalk programming environ-ment: www.squeak.org


Vol. 34 No. 1 Feb. 2017 105

Section 3 describes existing challenges in state-of-the-art commit tool support. In Section 4, wepresent our tool Thresher and give an introduc-tion to its scripting capabilities; we also present afoundation of scripts for developers to get started.We evaluate those scripts in Section 5 and discusslimitations and applicability to other environments.Section 6 sketches hypotheses and next steps forthis kind of commit tool support. Finally, we con-clude our thoughts in Section 7.

2 Related WorkThere are not many projects that try to pro-

actively involve developers in the process of com-mitting changes. Although, there are manyprojects that investigate how to automate the iden-tification of coherent change sets—only after com-mits have been taken place. Some projects deriverules by mining project histories, other projectscreate rules for changes that have detailed con-text information. Most of them deal with domain-specific characteristics, which emphasizes the needof adaptability and manual intervention when usingsuch tools.

Note that there is always the possibility to askprogrammers to explicitly set a scope before makingany changes, hopefully producing a clean, untan-gled history record. For example, the Mylar/My-lyn plugin for Eclipse provides that level of sup-port [19] [25]. We argue that such an approach isnot prepared for many software projects out therebecause it expects too much cautiousness while pro-grammers get distracted by side-tasks too easily.At the end of the day, untangling existing changesbecomes an issue and tools have to support that.

The tool Historef [14] takes an approach similarto Thresher. There, programmers can untangleedits in Java source code files to form task-levelcommits or do selective undo. — While Historefaccounts for the concept of a custom edit recorder,Thresher was designed to work with several kindsof change models, even coarse-grained ones. Bothtools do not provide automatic measures to pre-vent bugs introduced by reordering history events.Thresher operates on an object-oriented level andabstracts from files by means of packages, classes,and methods. Additionally, Thresher incorpo-rates the idea of adjusting the automated grouping

rules to accommodate domain-, project-, or task-specific requirements.

When mining repositories, existing changes areoften modeled and analyzed at a fixed level ofdetail. Herzig and Zeller [15] [16] applied ma-chine learning to adjust project-specific weights orthresholds for data dependencies, lexical distancemeasures, or test impact couplings. They analyzedcoherent change sets that were already assigned toparticular bug fixes. Kawrykow and Robillard [18]looked for behavior-preserving thus non-essentialchanges, which include rename-refactorings. Theyclaim that such changes affect coherence nega-tively. Kim and Notkin [20] derived logical rulesfrom change sets, which also identify anomaliesand hence tangling changes such as “All meth-ods X in classes that implement interface Y gotdeleted, except class Z.” This should also help de-scribe commit messages. — We derived a foun-dation of scripts from 5 programming sessions,which arguably reflect many important character-istics of object-oriented projects in Smalltalk. Onecan easily extend this approach with mining someSqueak/Smalltalk repositories to identify more cor-ner cases. As scripts represent concise and acces-sible descriptions of a particular change model, weargue that developers can easily adapt those scriptsto accommodate domain or project-specific needs.

When approaches are open to extensions inthe change model, identification and classificationmethods can benefit from any kind of context in-formation such as developer activity tracking. Forexample, Coman and Sillitti [6] tracked tool inter-actions and created the notion of time intervals ofintensive access to help detect activity switches;Zou and Godfrey [41] verified this approach in anindustrial setting. Robbes et al. [27] [28] also tracktimestamps and use time-coupling to improve re-call. Besides that, they track tool window usage,code authors, and annotations to indicate auto-mated refactorings. If actually noticed, the devel-oper can express the beginning of a new activityexplicitly. Yoon et al. [39] log all low-level eventsof the Eclipse code editor in an XML format to beprocessed by other tools. — Thresher promotesfine-granular change tracking without making as-sumptions about the level of detail that is tracked.For example in our Squeak/Smalltalk environment,there were logs for tool-controlled refactoring activ-



ities, which could be used to simplify script code.Other extensions to the change model could furtherimprove both scripts, results, and hence the overallutility.

Working with numerous fine-granular changesraises challenges for graphical tools from an infor-mation visualization perspective. Many approachesapply a timeline metaphor to provide overviewand details on demand as pluggable visualizationsin programming environments. Examples includeAzurite [40] and CodeTimeline [23]. — We arguethat common list, table, or tree views are capableof presenting huge amounts of data in a support-ive way. Problems will arise primarily if developershave no simple means to configure the views’ levelof detail. Thresher employs those means by giv-ing developers that required configuration supportin terms of adaptable scripts with direct feedbackafter script modifications.

3 Challenges in Existing ToolsIn this section, we highlight important factors

that substantiate the need for better tool sup-port when committing source code to a vcs. Wecover the nature of interleaving programming ac-tivities, state-of-the-art tool support, and specificsof the Squeak/Smalltalk change model—as we builtThresher in that programming environment.

3. 1 Interleaving Programming ActivitiesThe more programming activities interleave dur-

ing a session, the more important it is to untanglethem to commit only coherent and complete changesets. The number of actually traceable activitieswill be influenced by the developer’s task and thelevel of change tracking editing tools provide. Asfor the task, a simple bugfix may spawn only one ac-tivity but “drive-by corrections” and other activitiesinterleave quite often [21] [24]—those should be doc-umented in separate commits. As for the changetracking, the more editing events get tracked, thehigher the chance that a developer’s activity driftsget documented for the long term—all the moreif there are many modifications that rescind eachother during a session.

File-based environments (such as Java + Eclipse+ Git) compare the local working copy with thelatest version in the vcs to determine changes at

the level of text lines, which typically match pro-gram statements. We consider such an approachas coarse-grained because overwritten changes arenot tracked as coherent program entities but onlyat the level of character ranges. Object-basedenvironments (such as Smalltalk + Squeak +CoExist [32]) log any modification to the codebase by means of method and class changes. Thisallows for rewinding or replaying single decisionsand whole programming sessions. Such a changemodel is more fine-grained and persists more de-tails of a project’s history.

There is a programming approach called explo-rative/exploratory programming [9], where develop-ers are encouraged to make any change as they gowithout having a specific task in mind. They donot know upfront whether they will fix some bugsor add some neat features or clean-up some code.If software projects encourage emerging specifica-tions, a programming environment that supportsexplorative programming will help programmerswrite those specifications [31] [30] while the softwaresystem is growing. This approach frees program-mers from being too specific too early in highly un-certain scenarios like many research projects face.At the end of an explorative session, developerscan have numerous changes to untangle. We arguethat there is a need for better commit tool supportto even promote explorative programming and stillease comprehension of and learning from projecthistories.

3. 2 Interactive Commit Tool SupportFigure 2 gives an impression of how existing com-

mit tools make use of graphics and interaction.First and foremost, those tools present changes inscrollable lists with support for manual selectiononly. “Advanced” filtering covers presets such asall, none, and invert selection. It doesn’t matterwhether changes are file, method, or line-based:Such interfaces do not support untangling manychanges very well. Furthermore, multiple activitieshave to be considered one after another.

However, we do consider lists or tables as ap-propriate views because they can visualize chrono-logical order in a compact fashion. What existingtools miss is a way to filter and group changes ac-cording to some rules, which may not be expressedwith a single button-click but rather simple scripts.


Vol. 34 No. 1 Feb. 2017 107

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)

Additionally when seeing a complete and coherentchange set, developers may be better suited to pro-vide a descriptive commit message.

3. 3 The Squeak Change ModelSqueak has a direct notion of changes, change

files, and change sets†5—but all in a local sense andnot shared like common vcss such as Git. Trackedchanges include any source code modification af-fecting classes, methods, and their categories. InSqueak, change sets represent means to manuallyorganize changes to easily file-out and share them,for example, via mailing lists. There is a tool calledChange Sorter, which supports moving changes be-tween sets in case the developer forgot to switchbefore starting her activity. Overall, Squeak’s no-tion of changes provides a local history of every-thing that happens in the programming environ-ment. However, not all changes are reversible perse but, at the least, they can be replayed.

The Smalltalk community has a vcs calledSqueakSource†6 and an in-image tool called Monti-cello as counterpart (left in Figure 2). When com-mitting changes, Monticello only sees the latest ver-sions of classes and methods. Cherry-picking is sup-ported at the level of methods—not lines or rangesof text.

†5 Except for this section, we do not use the termchange set in a Squeak-specific way but in abroader sense throughout this paper.

†6 http://www.squeaksource.com

We make use of a recent research project calledCoExist [32], which extends Squeak’s changemodel by storing data to revert changes. It alsoadds the capability to Monticello to store fine-granular changes in SqueakSource such as two con-secutive modifications of the same method. In thatsense, CoExist elevates the fine-granular but localchange tracking of Squeak to the level of Monticel-lo/SqueakSource, which is now comparable to othervcss.

Building on top of many general concepts, wecreated Thresher for Squeak/Smalltalk but arearguably able to transfer our findings to other pro-gramming languages, tools, and environments.

3. 4 The Vivide Tool BuildingFramework

We implemented our tool Thresher with theVivide†7 tool building framework [34]. Vivide pro-vides a direct mapping between all graphical partsof the user interface and the internal tool logic. Itis implemented in Squeak/Smalltalk and builds ontop of the Morphic framework, which supports di-rect manipulation of all graphical objects. Withemploying this directness, the developer can easilyfind responsible data transformation scripts start-ing from a visual impression and express modifica-tions in the script source code. Due to this simpleyet powerful abstraction, the framework can up-date all running tools consistently. Thus, Vivide isboth a programming environment and a tool build-

†7 https://github.com/hpi-swa/vivide



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 resolvedmanually by the developer.

ing framework. Building tools means composingwidgets and writing script code.

The underlying concept of Vivide, that is de-scribing tools as data processing pipelines, alignswith our idea about analyzing code changes to re-cover programming activities. Developers shouldopen it after finishing a programming session to as-semble recent changes into groups, add descriptivemessages, and eventually commit them to the vcswith only a few clicks.

4 ThresherIn this section, we explain structure and use of

our tool as well as details about how changes areprocessed with scripts. The name “thresher” de-rives from the fact that we want to identify allchanges that belong to a certain activity and ig-nore the rest (for now)—just like the agriculturalmachine does with winnowing.

4. 1 Changes, Groups, andRecommendations

The overall goal is to make developers commit co-herent and complete change sets with a descriptivemessage. We classify a change set as coherent if itcontains only changes that origin from a single ac-tivity; it is complete if it contains all changes fromthat (completed) activity. In Thresher, scriptssupport to detect activity continuations and thusgrouping changes coherently. Completeness mightoften not be achieved on a scripting level because

some developer knowledge might be hard to expressor even ambiguous. Then, manual grouping viaThresher’s graphical interface will take place.

There are multiple scripts that modularize thechange analysis process in a sequence of stages. Atthe first stage, each change has its own group as-suming that each change belongs to its own pro-gramming activity. Intermediate stages either ex-pand those groups by merging them or propose rec-ommendations to be resolved manually. In the laststage, each resulting group is meant to be com-mitted to the vcs. The concept is illustrated inFigure 3.

In script code, programmers can iterate over allchanges, check for specific properties, and assignmatches to new groups. Those checks depend onthe information available; a stage may also add newinformation to changes by integrating external datasources. For example, results of static or dynamiccode analysis can be embedded this way.

4. 2 How to Use and When to UseThresher’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 ordercan be adapted.

Á Result View shows resulting groups and rec-ommendations. Developers can resolve recom-mendations with button clicks, change groupsvia drag-and-drop, and add descriptive mes-sages.

Â Diff View shows details about all selectedgroups to support developers to revise their de-cisions in detail.

Ã Stages View reveals intermediate results ofthe involved scripts, supports adapting (ad-d/remove/reorder) them as well as reviewing(or debugging) their effects.

There are several tasks that the developer accom-plishes when working with Thresher. Those de-scribe a seamless workflow and should encourage tofollow best practices by committing only coherent,complete change sets as well as adding descriptivemessages.

At first, the freshly opened Thresher windowanalyzes recent changes with the existing scriptsto form groups and add recommendations. Thesource view À lists all changes chronologically with


Vol. 34 No. 1 Feb. 2017 109

Fig. 4 The main views of Thresher: À local, uncommitted changes, Á computed change setswith recommendations, and Â detailed source code diffs.

a distinct label. The result view Á shows all result-ing groups, which contain these changes and maybeseveral ungrouped†8 ones. At the top of that view,discarded changes are listed such as recognized de-bugging code. All groups get single-letter labels foreasier recognition. At this point, the diff view Â isnot used because no group is selected.

After that, the developer reviews all group’s con-tents to verify coherence and completeness. Select-ing a group in the result view Á will reveal moredetails in the diff view and highlight the contents,which are automatically selected in the source view.Any group can be marked as ready-to-commit byclicking the checkbox near the group name. Thiswill separate that group visually by moving it tothe top as shown in Figure 4 for the group “bug fix:less than key.”

Group C contains 6 changes and 4 recommen-dations, which are highlighted in blue and orange.To see the content of single changes, the developercan hover over one of them in the source view.To discard the changes, the developer selects themand drag-drops them onto the “Discarded Changes”group.

Recommendations can either be single changesor whole groups as proposed by previous stages.When hovering over a recommendation, the reasonis shown in a tooltip (Figure 4, bottom right). The

†8 With “ungrouped” or “single changes” we meansingle-change groups.

developer can accept recommendations by clickingthe tick-icon next to it; the cross-icon rejects it.

After resolving all recommendations, the devel-oper can merge groups if she discovers a more ap-propriate intent. This happens by simply drag-and-drop groups on top of each other. It is also possi-ble to move selected changes (or groups) betweengroups.

Finally after reviewing a group, the developercan propose a descriptive name, which is displayedas the group’s name to help identify completeones. When she decides to commit, name anddescription are used as commit message. Besidesmanual naming, a short description of structuralchanges is appended automatically such as “addedclass SWA18World” and “modified method Player >>

render:.”Developers can invoke Thresher whenever they

want. They do not have to actually do the com-mit after they organized their changes, but theycan continue programming. However, we designedThresher to handle hundreds of fine-granularchanges at once. Hence we do not expect de-velopers to continuously use it within a program-ming session. We encourage developers to focus ontheir tasks and not to worry about tangled historyrecords.



4. 3 Scripting to Accommodatethe Project’s Domain

Developers can accommodate domain or project-specific needs by adding, removing, or reorderingstages. Each stage has a current script, whichdevelopers can access, modify, and re-execute toupdate the results. Once visible, the stages view(Figure 5 resp. Ã in Figure 4) shows intermediategrouping results. Scripts access the change modeland create groups with the help of a grouper likethis:

[:grouper | |newGroup|

newGroup := CustomGroup new.

grouper allChanges do: [:change | "See below."].

grouper addGroup: newGroup.

].

In our implementation, the scripting language isSmalltalk and scripts are just blocks evaluated withthe grouper instance automatically. Each scriptis like an anonymous function that will be calledwith a grouper as argument. That function hasno return value but can trigger side effects via thegrouper’s interface, that is, creating and addinggroups of changes.

If there are already existing groups, developerscan inspect their contents and consider them. Atthe beginning, there are as many groups as thereare changes. For each match in a script, thatchange’s current group is fetched and the nestedstructure of groups (Figure 3) is extended. Thefollowing snippet extends the example above:

"..." [:change |

change property = ’SomeFilter’ ifTrue: [

group add: (

(grouper groupOf: change) -> ’Reason␣for␣

addition.’

)]]. "..."

To write effective scripts, developers need toknow about possible change properties and thescripting language to write scripts. Here, filtershave the conciseness and expressiveness of theSmalltalk language and are only limited by the en-vironment’s loaded libraries. In particular, externaldata sources may also be queried and their answersused in such expressions. For example, one mightthink of a library that supports connecting emailaccounts with source code and hence reveal fur-ther information about the original author of the

changed piece of code.Thresher’s scripting capabilities can be summa-

rized like this: Scripts are high-level descriptionsof change characteristics and create or merge appro-priate groups while using a grouper for navigation.Different group classes represent distinct changecharacteristics with an optional pivot change, whichis a dedicated change used for identification. Forexample, a “class X renamed” change can be thepivot change for subsequent code updates. Initially,each change is in a single-change group. Arbitrarychanges can be put into a custom group. Groupsare units of reuse in scripts. A grouper supportsnavigating changes in the current group hierarchyand manages top-level groups across all scripts. Itis not meant to be extended. Recommendationsare created automatically if changes are associatedwith two distinct groups.

To present a more elaborate example, the fol-lowing script analyzes changes for method addi-tions/removals and combines them with all othermethod changes that update corresponding mes-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)]].

"Add new group to hierarchy."

grouper addGroup: group]].

Here, associations, which attach a textual de-scription as reason to each change, are used to fillgroups with changes. Developers do not have to


Vol. 34 No. 1 Feb. 2017 111

provide reasons but debugging unexpected resultscan benefit from such contextual explanations.

With only 19 lines of Smalltalk code, the devel-oper can automate such an untangling of changes.If existing changes are ungrouped, the grouper willjust create new groups. If they were already as-signed to groups in preceding stages, Thresherwill handle conflict resolution and may add recom-mendations because changes can only have a singlegroup. Developers do not have to deal with conflicthandling when writing scripts.

Scripts can also modify existing groups that werecreated by previous stages. By default, scriptsdo not modify previous decisions but add, merge,or recommend new changes from emerging groups.For example, two groups of the same kind suchas MethodAddOrRemoveGroup are usually merged andnot added as sub-groups. Eventually, top-levelgroups are important for the developer becausethose groups are meant to be committed.

Developers can add, remove, or edit Thresher’sscripts whenever they want—even during a regu-lar programming session. They can try out ideas,keep the good ones, discard the useless ones. Wethink that once the project domain and source codeconventions become clear developers do rarely haveto modify the existing scripts. Hence, scripting isno ongoing activity in projects that make use ofThresher. We expect the additional costs to learnand use the scripting language to amortize quickly.

4. 4 Towards a Foundation of ScriptsWe implemented a set of complementary scripts

that aim for detecting most characteristics as ex-tracted from several programming sessions [33]. Inmost cases, they use structural/code change infor-mation but they may also consider chronologicalaffinity. These assumptions encode the Smalltalklanguage characteristics besides Squeak’s changemodel and hence serve as a valid baseline forother projects in the Squeak/Smalltalk environ-ment. Due to space constraints we cannot print allscripts’ details here but will only summarize theirintents:

1. Consecutive grouping All consecutivechanges on the same source code artifact†9 are

†9 Source code artifacts can be packages, classes, ormethods.

grouped.2. Refactoring grouping All changes that

were triggered by tool-driven refactorings aregrouped. Depends in respective hints beingpresent in the change data.

3. Renaming grouping Detects a manual ortool-driven renaming of a source code artifactand groups it with all consecutive changes ofthe same kind. Affects also renamed variables.

4. Organizing grouping All consecutivechanges that reorganize software artifacts aregrouped. This includes class categories andmethod protocols.

5. Added/removed-method grouping Theaddition or removal of a method is groupedwith all changes that update the respectivemessage sends in the source code. Appliesstatic analysis to locate all sends.

6. Added/removed-variable grouping Theaddition or removal of an instance/class vari-able is grouped with all changes that updatethe respective references in the source code.

7. Added/removed-class grouping The ad-dition or removal of a class is grouped with allchanges that concern this class’ methods, vari-ables, and references.

The last three stages add recommendations:8. Close-to-artifact recommendation Single

changes are recommended to groups whosechanges affect the same artifact. Considerschronological affinity.

9. Close-to-polymorphism recommenda-tion Single changes are recommended togroups that concern method additions/re-movals but are ambiguous due to polymor-phism. Considers chronological affinity.

10. Pretty-print recommendation Singlechanges of cosmetic nature are recommendedto groups whose changes affect the same arti-fact if chronological affinity is high. If there isno such group, those changes are merged into anew group. Such changes include modificationof whitespace or comments, renaming of tem-poral variables, or cascading message sends.

With this focus on rules to combine rather thansplit changes, these scripts do not detect activityswitches but rather describe continuations. Fromone stage to another, scripts merge existing groupsof changes into bigger ones. Therefore, the or-



Fig. 5 The stages view in Thresher supports exploring intermediate results andadapting the scripts.

der of scripts can influence the results. For now,Thresher should stop processing if further merg-ing might decrease coherence of groups. Splittingup groups in scripts and hence describe activityswitches would be a valuable addition to our con-cept and is considered future work.

5 Evaluation of ScriptsIn this section, we evaluate the accuracy of the

basic scripts in Thresher, which we derived froma programming study [33]. We then estimate themanual effort that remains to complete the map-ping of all changes to their activities—by interact-ing with the tool’s graphical interface.

We have not yet evaluated to overall utility ofThresher. To some extent, we rely on the pos-itive effects of the Vivide programming environ-ment [34], in which Thresher runs. This, how-ever, remains subject to further research.

5. 1 Analyzing Programming SessionsOur proposed scripts are based on sample

data, which Steinert et al. collected during a lab

study [33] with 22 developers that had the task toimprove source code of a game in 2-hour sessions.The number of changes range from 40 to 250 persession. We manually mapped those changes to ac-tivities, which included debugging, refactoring, andcode clean-up. From this laborious activity, wederived several scripts that should automate thismapping process in terms of coherent groups of con-secutive changes and which can be combined to as-semble scattered change runs. Reconsider Figure 1for the distinction of tangled and scattered changes.

In particular, we chose 5 out of the 22 sessionsas representatives because their changes containedmany refactorings or frequently interrupted activi-ties with much tangling and many revisions; someof them contained at least one larger refactoring.We reviewed each fine-grained change manuallyand added it to coherent, complete sets to get kindof a gold standard for our analysis. Some developerscreated their own commits with Monticello, whichwe only partially took into account because at thattime, it forced them to commit all changes at once.We did not interview the developers but were fa-


Vol. 34 No. 1 Feb. 2017 113

miliar with the domain of the game and its sourcecode. Eventually, we identified recurring character-istics that indicate strong relationships or obviousactivity switches as summarized in Table 1. Weused the 6th data set to “simulate” a programmingsession whose contents were not explicitly used toderive those scripts.

5. 2 Precision, Recall, and Manual EffortWe quantify the accuracy of Thresher’s basic

scripts in terms of precision and recall, as knownfrom the domain of information retrieval [36]. Theresult’s precision describes the percentage of truepositives, the result’s recall accounts for false neg-atives. We describe the accuracy with sets ofchanges to reflect the way Thresher works. Inaddition to precision and recall, we quantify themanual effort that is necessary to get an ideal re-sult.

For the accuracy, we compare the expected set ofrelated changes with the calculated one. Let the ex-pected groups be AE = {3, 5, 6} and BE = {1, 2, 4}where digits indicate a change’s running number.Let the calculated groups be AC = {3, 5}, BC =

{6}, and CC = {1, 2, 4}. The expected set of rela-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}}by expanding the groups into pair sets. The preci-sion is now defined as P = |E ∩ C| / |C| and recallas R = |E ∩ C| / |E|. In this example, precision is1.0 (100%) and recall is 0.67 (67%), which indicatesthat all calculated groups are coherent but manualreviewing and merging is required for completion.

For the manual effort, we consider two extremecases: developers are either directly able to as-sign changes to activities after reviewing them once(min = 2·nchanges), or they have to look through allchanges for each activity again (max = nactivities ·nchanges). When using Thresher, this effort is re-duced because it depends on the number of pro-posed groups instead of single changes. The de-veloper clicks to accept/reject single recommenda-tions or all at once. Drag-and-drop interactions canmerge groups or single changes.

5. 3 ResultsWe achieved a precision of 96% to 100% for our

five data sets as summarized in Table 2. Thus, wemet our goal of avoiding false-positives in groups byfavoring coherence over completeness in the scripts.

The upper part in the table shows informationabout the session size by means of number ofchanges and number of expected groups. The mid-dle part shows the accuracy as described above. Itincludes the number of calculated groups that ex-actly match the expected commits and the numberof recommendations that should help reduce man-ual effort. The lower part approximates the manualeffort including the minimal amount of click/drag-and-drop actions in the user interface.

The recall indicates that 33% to 57% of the re-lations, which express activity continuation, weredetected by our scripts. For the data set V, we sim-ply adapted the script to increase recall; we expectdevelopers to do the same when facing many smallgroups. Regarding the number of groups comparedto the expected commits, an expected commit isroughly spread over two to three groups. Sincesome commits were completely detected (see “#Exact Matches”), other commits are spread overmore than three groups.

We explicitly counted the number of manual ac-tions; this number can be approximated as twotimes the number of expected commits because thiscorresponds to the distribution of commits overproposed groups. For some data sets this is evenless, which means that the given recommendationshelp reduce manual effort. Notice that the devel-oper could also accept or reject all recommenda-tions for a particular group with a single click.

Programming session VI was analyzed to give afirst impression of the quality and reusability ofThresher’s base scripts. We extracted patternsfrom sessions I to V, which had to be adapted toconsider several corner cases in session V. A pre-cision of 100% and a recall of 25% for session VI,however, indicate a satisfying result without fur-ther adaptation needed. The developer does onlyhave to assemble the proposed groups with the helpof recommendations and manual drag-and-drop in-teractions.



Table 1 Characteristics that rendered data sets interesting forderiving a foundation of scripts in Thresher.

Characteristics Data setsProgramming breaks between different refactorings (activity switch) I II IVChanged statements for debugging output or breakpoints (to be ignored) I VConsecutive changes in the same artifact I II III IV VConsecutive renamings of artifacts including updates of their uses in the code IVConsecutive reorganization of methods’ protocols I V VIChanges of methods in different classes with shared protocol I III V VISimilar patterns in identifiers of artifacts II III IV VIAdded/removed a method and update their uses I II III IV V VIAdded/removed an instance/class variable and update their uses I IV V VIAdded a class and initial methods/variables as well as initial uses I VIRemoved a class and update their uses I II III V VI

Table 2 Evaluation results comparing manual analysis (expected groups)with the scripts of Thresher (calculated groups).[* Scripts adapted for V due to low recall]

Data set I II III IV V V* VINumber of Changes 121 57 39 74 157 157 211Number of Expected Groups 8 5 6 7 4 4 4AccuracyNumber of Calculated Groups 20 10 7 12 58 34 40Number of Exact Matches 1 3 4 1 1 1 0Number of Recommendations 20 4 2 21 32 31 22Precision (%) 96 100 100 100 100 100 100Recall (%) 35 43 57 35 1 33 25EffortMinimum Interactions 242 114 78 148 314 422

with Thresher 40 20 14 24 116 48 80Maximum Interactions 968 285 234 518 628 - 844

with Thresher 160 50 42 84 232 96 160Ratio (%) 17 18 18 16 37 15 19Number of Manual Merge Actions 16 6 4 14 - 16 31

5. 4 Discussion and Threats to ValidityAfter the manual analysis of all changes, we con-

firmed that Thresher’s scripts cannot run fullyautomated but developers have to intervene. Onecould have expected even better results becausewe designed the scripts to detect the groups asfound manually in the first place. Still, our evalu-ation approach confirmed that even a simple set ofscripts can support developers in the commit pro-cess. We argue that there can hardly be a fully-automated approach that works without any hu-man intervention. On the one hand, several deci-sions rely on the developer’s insights in the partic-

ular domain and project, which were not material-ized in the change data. On the other hand, ourscripts may not correctly reflect the characteristicsfound. Although we cross-checked several charac-teristics among us, there was not always consensus.For example, there were several method extractionsacross the code base and one of us argued to com-bine them into a refactoring group but another onewould rather consider more domain-specific infor-mation and split them apart. We found similar con-clusions in [6] [11] [29]. Thresher is well suited tointeractively help developers to decide which par-ticular characteristics to pursue and when to merge


Vol. 34 No. 1 Feb. 2017 115

proposed groups.We derived the scripts and tool requirements

from only 5 programming sessions. Althoughwe found an arguably representative spectrum ofchange characteristics for the Squeak/Smalltalkprogramming environment, other sessions may con-tain more special cases. As different kinds of activi-ties influence the number and structure of changes,we should analyze more sessions that do not mainlydeal with refactorings and bug fixing but also withfeature implementations like classified by Hattoriet al. [12]. Those could reveal further characteris-tics [27] [38] such as more additions and less modi-fications of methods.

The concept of recommendations accounts forscripts’ interdependence; it helps developers ad-just the proposed groups before committing them.However, misleading recommendations may neg-atively affect the coherence of a change set.Thresher can miss to recommend the actually cor-rect group; we have no means to prevent that.

Our scripts detect activity continuations ratherthan switches and thus related changes rather thanchecking for “unrelatedness”; which is undecid-able [15]. This may be contrary to how developerswould manually select coherent change sets from achronologically ordered list of recent changes. Ad-ditionally, our scripts do not cope with successiveactivities but would merge them into a single one.For example, the developer may rename methods asa refactoring (A) and then use those to implementa new feature (B succeeding A).

We reduced the implementation and computa-tion effort of the scripts by prepending a static anal-ysis of the methods’ source code to add useful infor-mation such as changed references, variables, andmessage sends. When implementing such a tool in adifferent environment, the benefits of such cachingdepends on the existing change model.

Our scripts only detect low-level relations be-tween changes. Future work should include moreabstract characteristics such as design patterns [10]as previously investigated by [17] [22]. Dynamicanalysis could also reveal interesting relations by,for example, collecting concrete type informa-tion [13] to be used in scripts.

Applicability to other object-oriented languagesand environments is straightforward because theconcept of classes and methods is reflected in many

of our scripts. Languages with fundamentally dif-ferent concepts, such as logic programming, mayreveal quite different characteristics. The script-ing language may also differ from the one used inthe programming environment, which was not thecase in Squeak/Smalltalk. We think that it is agood idea to provide Thresher’s level of supportin other environments as well. Further research hasto reveal whether there are any drawbacks if onehas to design a custom scripting language for pro-grammers to make the idea of Thresher feasible inmore static or closed environments such as Eclipseor Visual Studio.

We could also apply Thresher directly to otherprogramming languages. For example, we can mod-ify the scripts of Thresher to provide a level ofsupport comparable to Historef [14], which targetsfiles with Java source code. In general, there areways to provide language-agnostic tool support ina Smalltalk environment because programming lan-guages can be integrated as needed [7].

6 Hypotheses and Future WorkBased on our experience with implementing

Thresher in Squeak/Smalltalk and providing afoundation of scripts based on the lab study [33],we argue that this can only be the first step to-wards a tool that supports developers in any kind ofsoftware project. Our foundation of scripts as pre-sented in Section 4. 4 has to be stress-tested withadditional data. At the time of writing, we derivethe following hypotheses:• Given a foundation of scripts that consid-

ers a particular programming language and itschange model, developers will rarely have toadapt those scripts except for project-specificneeds.

• If developers are knowledgeable about thescripting capabilities in such a commit tool,they are more likely to improve their personalworkflow by taking advantage of that.

• If developers adapt such scripts for project-specific needs, they will make fewer mistakesand save time during the commit process.

Besides running experiments to test those hy-potheses, we are eager to improve the general ideaof how fine-granular changes might be combinedinto coherent and complete groups. In addition



to describing the continuity of activities betweenchanges, we think that it is important to also splitup bigger groups to indicate activity switches andthus separate commits. Finally, expressing rules ofdependency relationships in scripts is valuable sothat the correct commit order of change sets canbe ensured, too.

Furthermore, we want to try out visualizationsbased on structures other than lists, tables, ortrees. For example, recommendations across groupboundaries might be better displayed with a graphsimilar to Figure 3. Finally, we have to general-ize our scripting approach to other programmingsystems and their change models. File-based mod-els, for example, may reveal different traits thanobject-based ones.

For all these improvements, we see a need for datafrom programming sessions that go beyond simplerefactoring tasks such as adding features or fixingbugs. Only then, we can establish a useful scriptinginterface to support programmers to accommodateproject-specific requirements.

7 ConclusionWe presented Thresher, a scriptable, interac-

tive, graphical tool that developers can use af-ter programming sessions to identify coherent andcomplete sets of fine-granular changes to be com-mitted to a vcs. A foundation of scripts automat-ically detects related changes that indicate activ-ity continuations; developers then manually assem-ble those scattered groups into complete activitydescriptions. We argue that it is very importantto involve the actual developer into this processbecause there is much tacit knowledge about theproject and its domain that cannot be manifestedin code or change structures.

We showed that our foundation of scripts proposegroups with a precision of almost 100% indicatingthat developers can rely on their coherence and fo-cus on adjusting their completeness with respect toan activity. We argue that such tool support pro-motes the usage of fine-granular changes, which isbeneficial for explorative programming strategies—omitting explicit checkpoints—and detailed track-ing of project histories.

AcknowledgmentsWe wish to thank Jens Lincke, Lena Herscheid,

Lysann Schlegel, Mark Rooney, Marko Röder, andPhilipp Tessenow for fruitful discussions and valu-able feedback. We gratefully acknowledge the fi-nancial support of HPI’s Research School†10 andthe Hasso Plattner Design Thinking Research Pro-gram.†11

References

[ 1 ] Barnett, M., Bird, C., Brunet, J. and Lahiri,S. K.: Helping developers help themselves: Auto-matic decomposition of code review changesets, inProceeding of the 37rd International Conference onSoftware Engineering (ICSE), ACM/IEEE, 2015.

[ 2 ] Boehm, B. W.: The high cost of software, Prac-tical Strategies for Developing Large Software Sys-tems, (1975), pp. 3–15.

[ 3 ] Bohner, S. A. and Arnold, R. S.: SoftwareChange Impact Analysis, John Wiley & Sons, 1996.

[ 4 ] Borg, M. and Runeson, P.: Changes, evolution,and bugs: Recommendation systems for issue man-agement, in Recommendation systems in softwareengineering, Springer, 2014, pp. 477–509.

[ 5 ] Buse, R. P. L. and Weimer, W. R.: Automat-ically documenting program changes, in Proceed-ings of the 25th International Conference on Au-tomated Software Engineering (ASE), IEEE/ACM,2010, pp. 33–42.

[ 6 ] Coman, I. D. and Sillitti, A.: Automated iden-tification of tasks in development sessions, in Pro-ceedings of the 16th IEEE International Conferenceon Program Comprehension (ICPC), IEEE, 2008,pp. 212–217.

[ 7 ] Stéphane, D., Gîrba, T., Lanza, M. and DemeyerMoose, S.: : A collaborative and extensible reegi-neering environment, in Tools for Software Mainte-nance and Reengineering (RCOST), Software Tech-nology Series, 2005.

[ 8 ] Duvall, P. M., Matyas, S. and Glover, A.: Con-tinuous integration: Improving software quality andreducing risk, Pearson Education, 2007.

[ 9 ] Gabriel, R. P.: I Throw Itching Powder at Tulips,in Proceedings of the ACM Symposium for NewIdeas, New Paradigms, and Reflections on Every-thing to do with Programming and Software (On-ward!), ACM, 2014, pp. 301–319.

[10] Gamma, E., Helm, R., Johnson, R. and Vlis-sides, J.: Design patterns: Elements of reusableobject-oriented software, Pearson Education, 1994.

[11] Gold, N. and Mohan, A.: A framework for un-

†10 www.hpi.uni-potsdam.de/research_school†11 www.hpi.de/en/research/design-thinking-

research-program


Vol. 34 No. 1 Feb. 2017 117

derstanding conceptual changes in evolving sourcecode, in Proceedings of the 19th International Con-ference on Software Maintenance (ICSM), IEEE,2003, pp. 431–439.

[12] Hattori, L. P. and Lanza, M.: On the na-ture of commits, in Proceedings of the 23rd Inter-national Conference on Automated Software Engi-neering Workshops, 2008, pp. 63–71.

[13] Haupt, M., Perscheid, M. and Hirschfeld, R.:Type harvesting: A practical approach to obtainingtyping information in dynamic programming lan-guages, in Proceedings of the 2011 Symposium onApplied Computing (SAC), ACM, 2011, pp. 1282–1289.

[14] Hayashi, S., Hoshino, D., Matsuda, J., Saeki,M., Omori, T. and Maruyama, K.: Historef: A toolfor edit history refactoring, in Proceedings of the22nd International Conference on Software Analy-sis, Evolution, and Reengineering (SANER), IEEE,2015, pp. 469–473.

[15] Herzig, K. and Zeller, A.: Untangling changes.Unpublished manuscript, September, 2011. http://www.st.cs.uni-saarland.de/publications/files/herzig-tmp-2011.pdf, accessed: July 1, 2014.

[16] Herzig, K. and Zeller, A.: The impact of tangledcode changes, in Proceedings of the 10th Interna-tional Workshop on Mining Software Repositories(MSR), IEEE, 2013, pp. 121–130.

[17] Heuzeroth, D., Holl, T., Hogstrom, G. andLowe, W.: Automatic design pattern detection,in Proceedings of the 11th International Workshopon Program Comprehension (IWPC), IEEE, 2003,pp. 94–103.

[18] Kawrykow, D. and Robillard, M. P.: Non-essential changes in version histories, in Proceedingsof the 33rd International Conference on SoftwareEngineering (ICSE), ACM/IEEE, 2011, p. 351.

[19] Kersten, M. and Murphy, G. C.: Mylar: ADegree-of-Interest Model for IDEs, in Proceed-ings of the 4th International Conference on Aspect-oriented Software Development (AOSD), ACM,2005, pp. 159–168.

[20] Kim, M. and Notkin, D.: Discovering and rep-resenting systematic code changes, in Proceedingsof the 31st International Conference on SoftwareEngineering (ICSE), IEEE, 2009, pp. 309–319.

[21] Ko, A. J., DeLine, R. and Venolia, G.: In-formation Needs in Collocated Software Develop-ment Teams, in Proceedings of the 29th Interna-tional Conference on Software Engineering (ICSE),ACM/IEEE, 2007, pp. 344–353.

[22] Kramer, C. and Prechelt, L.: Design recoveryby automated search for structural design patternsin object-oriented software, in Proceedings of the3rd Working Conference on Reverse Engineering(WCRE), IEEE, 1996, pp. 208–215.

[23] Kuhn, A. and Stocker, M.: CodeTimeline:Storytelling with Versioning Data, in Interna-

tional Conference on Software Engineering (ICSE),IEEE/ACM, 2012, pp. 1333–1336.

[24] Meyer, A., Fritz, T., Murphy, G. C. and Zim-mermann, T.: Software Developers’ Perceptions ofProductivity, SIGSOFT FSE, ACM, 2014.

[25] Murphy, G. C., Kersten, M., Robillard, M. andCubranic, D.: the emergent structure of develop-ment tasks, in Proceedings of the European Con-ference on Object-oriented Programming (ECOOP),Springer, 2005, pp. 734–749.

[26] Robbes, R. and Lanza, M.: A change-basedapproach to software evolution, Electronic Notesin Theoretical Computer Science, Vol. 166 (2007),pp. 93–109.

[27] Robbes, R. and Lanza, M.: Characterizing andunderstanding development sessions, in Proceedingsof the 15th International Conference on ProgramComprehension (ICPC), IEEE, 2007.

[28] Robbes, R., Pollet, D. and Lanza, M.: Logicalcoupling based on fine-grained change information,in Proceedings of the 15th Working Conference onReverse Engineering (WCRE), IEEE, 2008, pp. 42–46.

[29] Robillard, M. P., Coelho, W. and Murphy, G. C.:How effective developers investigate source code:An exploratory study, IEEE Transactions on Soft-ware Engineering, Vol. 30, No. 12 (2004), pp. 889–903.

[30] Sandberg, D. W.: Smalltalk and exploratoryprogramming, ACM SIGPLAN Notices, Vol. 23,No. 10 (1988), pp. 85–92.

[31] Sheil, B.: Environments for exploratory pro-gramming, Datamation, Vol. 29, No. 7 (1983),pp. 131–144.

[32] Steinert, B., Cassou, D. and Hirschfeld, R.:CoExist: Overcoming aversion to change - Preserv-ing immediate access to source code and run-timeinformation of previous development states, in Pro-ceedings of the 8th Symposium on Dynamic lan-guages (DLS), ACM, 2012, pp. 107–118.

[33] Steinert, B. and Hirschfeld, R.: How to com-pare performance in program design activities: To-wards an empirical evaluation of CoExist, in De-sign Thinking Research: Understanding Innova-tion, Springer, 2014, pp. 219–238.

[34] Taeumel, M., Perscheid, M., Steinert, B., Lincke,J. and Hirschfeld, R.: Interleaving of Modifica-tion and Use in Data-driven Tool Development,in Proceedings of the ACM Symposium for NewIdeas, New Paradigms, and Reflections on Every-thing to do with Programming and Software (On-ward!), ACM, 2014, pp. 185–200.

[35] Tao, Y., Dang, Y., Xie, T., Zhang, D. and Kim,S.: How do software engineers understand codechanges?: An exploratory study in industry, in Pro-ceedings of the ACM SIGSOFT 20th InternationalSymposium on the Foundations of Software Engi-neering, ACM, 2012, p. 51.



[36] van Rijsbergen, C. J.: Information retrieval(second edition), Butterworths, 1979.

[37] von Mayrhauser, A. and Vans, A. M.: Pro-gram comprehension during software maintenanceand evolution. Computer (IEEE), Vol. 28, No. 8(1995), pp. 44–55.

[38] Williams, B. J. and Carver, J. C.: Charac-terizing software architecture changes: A system-atic review, Information and Software Technology,Vol. 52, No. 1 (2010), pp. 31–51.

[39] Yoon, Y. S. and Myers, B. A.: Capturingand Analyzing Low-Level Events from the CodeEditor, in International Workshop on Evaluationand Usability of Programming Languages and Tools(PLATEAU), 2011, pp. 25–30.

[40] Yoon, Y. S., Myers, B. A. and Koo, S.: Vi-sualization of Fine-grained Code Change History,in Proceedings of the 2013 IEEE Symposium onVisual Languages and Human-centric Computing(VL/HCC), IEEE, 2013, pp. 119–126.

[41] Zou, L. and Godfrey, M. W.: An industrial casestudy of Coman’s automated task detection algo-rithm: What worked, what didn’t, and why, inProceedings of the 28th International Conference onSoftware Maintenance (ICSM), IEEE, 2012, pp.6–14.

Marcel Taeumel

Marcel Taeumel ([email protected]) is a Research Assistant inthe Software Architecture Group atthe Hasso-Plattner-Institute (HPI).He received a master’s degree in

Software Engineering from the Hasso-Plattner-Institute, University of Potsdam, Germany. Seealso http://marcel.taeumel.eu.

Stephanie Platz

Stephanie Platz ([email protected]) is a Software Engi-neer at MarleySpoon GmbH, Ger-many. She received a master’s de-gree in Software Engineering from

the Hasso-Plattner-Institute, University of Pots-dam, Germany.

Bastian Steinert

Bastian Steinert ([email protected]) is a Product Man-ager at Signavio GmbH, Germany.He received a Ph.D. in ComputerScience from the Hasso-Plattner-

Institute, University of Potsdam, Germany. Seealso http://www.bastiansteinert.org.

Robert Hirschfeld

Robert Hirschfeld ([email protected]) is a Professor of ComputerScience at the Hasso-Plattner-Institute (HPI) at the Universityof Potsdam, Germany. He received

a Ph.D. in Computer Science from the TechnicalUniversity of Ilmenau, Germany. See also http://www.hpi.uni-potsdam.de/swa.

Hidehiko Masuhara

Hidehiko Masuhara ([email protected]) is a professor at theDepartment of Mathematical andComputing Science, Tokyo Insti-tute of Technology. He received his

B.Sc., M.Sc., and Ph.D degrees from Department ofInformation Science, University of Tokyo in 1992,1994, and 1999, respectively. His research inter-est is in programming languages and programmingenvironments, especially advanced modularizationmechanisms, optimization techniques, code recom-mendations, and debuggers. Before joining TokyoInstitute of Technology, he worked as an assistantprofessor, a lecturer, and an associate professor atGraduate School of Arts and Sciences, the Univer-sity of Tokyo.

Unravel Programming Sessions with THRESHER: Identifying …€¦ · Unravel Programming Sessions...

Documents

Transcript of Unravel Programming Sessions with THRESHER: Identifying …€¦ · Unravel Programming Sessions...