8/22/2019 Extended Todos

1/5

Extended Todos

Improving the representation and management of code annotations without

losing their lightweight characteristics.

Claudio A. AnlikerDepartment of Informatics, University of Zurich

Binzmuehlestrasse 14Zurich, Switzerland

claudio.anliker@uzh.ch

Andr N. MeyerDepartment of Informatics, University of Zurich

Binzmuehlestrasse 14Zurich, Switzerland

andre.meyer@uzh.ch

1. ABSTRACTIt is common practice that developers use task annotationsin their code to improve its readability and the communi-cation between team-members. Their fast creation makesthem easy to forget, as there is usually no connection toa planning tool and only a limited view to manage them

available. We introduce a new approach by connecting taskannotations with an agile planning tool, improving their rep-resentation by adding contextual information and extendingtheir default view. This approach aims to extend the verylimited possibilities present in current modern IDEs suchas Visual Studio, but also to keep the lightweight charac-teristics. An operability study and a small-scale evaluationshows the approachs great potential, despite its prototypenature and many possibilities and ideas for future work.

2. INTRODUCTIONProgram comments are often used as a common practicefor improving code readability and the communication be-tween team-members, by explicitly specifying programmers

intentions and assumptions. In a study by Storey et al. [4],they found out that 78 of 81 of the participants use taskannotations to write small, lightweight side notes into theircode. This side note may serve a developer as a reminder ofa future task, such as duplicated code, a small bug, a pos-sible optimization or a reference check. The power of thosetask annotations, from now on referred as todos, is the verysimple and quick creation of a new item as described in [2].Without ever leaving the editor window, the developer cancreate a new todo by typing //TODO: ... (or somethingsimilar, depending on the programming language and theIDE). Some IDEs have a predefined, often extensible set ofkeywords to b e used. For example, Visual Studio offers de-velopers the keywordsTODO,HACK, andBUGper default.

Todos usually do not contain a lot of information about theirreproduction. Sometimes, they look as short as HACK: doproperly later or TODO: Add new button here. This

missing context makes it difficult to complete them and tounderstand the reason for their creation. In some cases, itcould make sense to extract a new work item or bug froma todo and store it in the planning tool. However, this stepis time consuming and requires the developer to leave thecurrent editor window. With the todo not being stored in

the planning tool, it fails to remind developers and man-agers about tasks that need to be performed [3]. As soonas a todo is extracted as an item into the planning tool, itcan be integrated in the normal planning cycles, such as thescrum meeting in an agile project. Modern IDEs, such asEclipse or Visual Studio, aggregate todos and list them in aseparate view. This list grows fast and it is difficult to keepan overview and the context of the lists items. Those viewsonly offer limited possibilities to filter, sort and search thosetodos. This makes the yet powerful todos a possible threatto the success of a software project. They might be forgottenas the application relies on open issues. These issues couldnot only be some possible stability or p erformance optimiza-tions, but also break the system and its maintainability. We

consider it as highly desirable to improve the representationof these todos and make their management more powerful.Based on these reasons, we state the following research ques-tion:

RQ: Can we find an intuitive and easily deployable approachto improve the representation of todos and make them morepowerful in a team-project without losing their lightweightcharacteristics?

Our research question focuses on a new approach that ex-tends the present and well-established concept of todos. Toachieve this, we aim to integrate the rudimentary todo-concept of a popular IDE with a planning tool. Additionally,we want to provide developers with an extended and morefeature-rich view, by letting them filter, search and sort to-dos and showing more relevant information. We expect thisto simplify the management of responsibilities and the as-signment of tasks among team members tremendously. Ourapproach is aimed to be simple and intuitive and retain thetodos lightweight characteristics and simple creation.

This paper is structured as follows. Section 3 describes theapproach. Section 4 presents the prototype, some detailsabout its implementation and ideas for future versions of thetool. Section 5 presents the results of two preliminary stud-ies. The prototype is then compared to other similar tools

8/22/2019 Extended Todos

2/5

and add-ins in Section 6 and our contributions discussed inSection .

3. APPROACHThe main goal of our project is to provide a tool to sim-plify the management and maintenance of todos and con-nect them to the teams planning tool. To achieve thisgoal, we have to provide the user with an extended rep-

resentation of the todo by adding contextual informationsuch as the creator, creation date, and assignee. We intendto further extend the described rudimentary todo conceptby connecting the todos to a planning tool to share todoswith co-workers. We expect this to simplify the manage-ment of responsibilities and the assignment of tasks amongteam members tremendously. In addition, the quality ofthe software might increase as the implementation of the to-dos can be planned and is not forgotten. Our approach isaimed to add this functionality without harming the todoslightweight characteristics and keeping it simple and intu-itive.

Integrating todos into a planning tool is not straightfor-

ward as it enriches them with new information, which mightbring the risk of reducing their lightweight structure. Agileplanning tools such as Microsofts Team Foundation Server(TFS)1 require additional information to create new workitems, bugs, feature requests or code review requests. Someof this information, such as the current iteration path or thecreator of the item, could automatically be inferred from thecontext. If developers have to provide this kind of data man-ually each time they create a new item on TFS, the usabilityof the approach would suffer and developers would not havea benefit in creating items directly from todos. Therefore,the tool should simplify this process by auto-completing asmuch information as possible and reducing user input to aminimum.

The different purposes of todos do not always require themto be stored in the planning tool. Todos should still be aseasy to create as before, regardless of the changes of ourapproach. Therefore, we have to ask the user as soon as hewrites a todo if he wants to export it or just keep it locallyas a standard todo. This could be achieved with a pop-updialog, containing prefilled contextual information to sim-plify the export to the planning tool if the user desires.

To benefit of the additional data of our todos, we want tosupply the users with a new view, which shows them rel-evant information. As the information a developer mightwant to see is individual, users should be able to customize

the view. This customization can be achieved by a filterand search functionality and a reasonable default selectionof information to be shown.

Finally, we want to extend the predefined set of keywordsused for a todo to let the user easily specify the type of itemthat is created on TFS. The reason for this extension is, thatmeaningful customized annotations can make tasks, such asorganization and refinding of todos, easier for the individualdeveloper [2]. You may find the mapping of the todo typesto the types on TFS in Table 1. As an example, if the user

1http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx

Extended Todo Keywords Item created on TFS

TODOHACKWTF

Work Item

CHECKME Code Review RequestBUG BugTOCREATE Feature RequestNOTE nothing

Table 1: Mapping of the different types of todos to

the items created on TFS.

writes something like TOCREATE: create a delete buttonhere, our add-in will ask the developer if he wants to savethe todo as a feature request on TFS.

4. PROTOTYPEThe implementation of our approach is an add-in for Mi-crosofts IDE Visual Studio, which integrates with the ver-sion control and collaboration environment Team Founda-tion Server (TFS). The add-in is programmed with the Win-

dows Presentation Foundation (WPF) framework (version4.5). At startup, it shows a prompt to login to the TFS.This is required to connect todos to TFS. It is worth to men-tion that Visual Studio provides a way to create a new TFSwork item itself. However, the interface is very heavyweight,asking for lots of information and is further not connectedto todos in any way. Using our add-in, the process of cre-ating an item from a todo on TFS is highly simplified andhappens as follows: As soon as a todo is created, the add-inopens a pop-up window as briefly discussed in the previoussection. This pop-up is designed to be both lightweight andcomplete, which is why it provides the possibility to mod-ify any information related to the todo. The information,which we consider less likely to be changed from its referredvalues is hidden behind an expander control by default. Thepop-up window is shown in Figure 1.

The discard button of the pop-up is focused by default, suchthat a single toggle of the enter key (or Alt+D) cancels theexport. Similarly, the user can trigger the upload to the TFSvery fast using the key combination Alt+S. The text boxesin the pop-up are editable and every change is automati-cally transferred to the code to provide consistency. Theview of our add-in uses a DataGrid and allows dynamicallyshowing or hiding columns as the user desires. Furthermore,DataGrids allow reordering columns to fit the individualdevelopers requirements b est. We implemented the filterfunctionality using a combination of a textbox to add a textpattern and a dropdown to select a specific column to search

for pattern matches, whereas by default all columns are se-lected. The extended todos view is shown in Figure 2.

Our implementation has potential for improvements, whichis inherent in its prototypical nature. A long-term projectto enhance the tool could especially improve the usability.

4.1 Possible ImprovementsA significant limitation of our implementation is that Vi-sual Studio does not provide a unique ID for todos. Sinceproperties such as line number, assignee and description canchange over time, they are not suitable to be used as an

8/22/2019 Extended Todos

3/5

ID. Unfortunately, creating an ID is inevitable to maintainthe set of todos. The only way to bind the ID to the cor-responding todo was to write it in the code. Since this IDis also reused as a marker if a todo is already incorporatedto the add-in, every todo gets an ID, independently if it isexported to TFS or not.

Initially, it was planned to store all the additional infor-

mation concerning a todo outside the code in a separate fileand reference to it via the global ID. However, this approachcaused merging issues with version control as soon as differ-ent users added todos into the same source file. Therefore,we decided to write all of the information into the source fileto avoid additional merging conflicts, which are not directlyrelated to code and have to be hidden from the developeranyways. This tradeoff will be addressed in future work asthe additional data corresponding to the todos pollutes thesource code. A solution to this problem would increase thetools usability tremendously.

Another potential improvement concerns the synchroniza-tion between todos and the TFS items. In the current im-plementation, the TFS and our add-in are not tightly cou-pled, as changes are not immediately reflected on TFS andthe other users views. This is a desirable optimization fora future implementation. Additionally, the items created onTFS could be further enriched with information about thesource code context in which they were created.

Another idea for future work is to consider hiding the todosin the source code, as it is discussed in the work by Parnin etal. [1]. The todos would still be tracked and shown withinthe view, but they are not shown in the .cs-files to keepthe code clean. Nevertheless, this suggestion does not cor-respond to the nature of task comments as todos are calledin the Visual Studio domain. Therefore, an accurate evalu-ation of this feature is inevitable to make a prediction on its

usability.

The view could benefit from further improvement too as itis limited to a DataGrid, whose structure is very similar toVisual Studiostask list. For example, the view could be im-proved with a treeview to group todos, e.g., by file, assigneeor sprint number to provide a further presentation possi-bility. To keep the possible improvements and future worksuggestions collocated, we anticipate here an input formu-lated by the participants of our study, which is presented inthe following section. Generally, the participants mentionedmany of the ideas we already noted for future work. Thisgave us good confidence in our own interpretation of the ap-proachs implementation. Additionally, they made one ma-

jor suggestion. They think it would be a nice improvementof the view if developers could modify the todos by click-ing on the corresponding row in the view, with automaticchanges in the source code and on the TFS.

5. EVALUATIONFollowing the implementation of the prototype, we ran twopreliminary studies to determine if the prototype works cor-rectly and to get early feedback from two potential users ofthe tool. The results of the studies are presented in thischapter.

Figure 1: The pop-up can be used to edit the todos

contents and create a new item on TFS.

Figure 2: The extended todos view lets the user

filter, sort and search for todos and shows more rel-

evant information.

5.1 Operability StudyDuring the development of the prototype, we used our ownadd-in to make sure it works as intended and meets ourgoals. This heavily influenced the final version, as we wereable to find issues and complicated or not intuitive processesat early stages. This also made it possible to use the pro-totype in early stages of development to find out how us-able it is in a real-world software project and how we wouldwork with it. As the foundation of the add-in is the cor-rect tracking of the todos in the users code, we run a smalloperability study to determine if the tracking is working asexpected. To do this, we used the most downloaded opensource project from Codeplex and compared the number oftodos shown in the originalTask Listview in Visual Studiowith the number of todos our add-in found. The examinedtool is called Python Tools for Visual Studio2 and is basedon more than 249,000 lines of code and text. Our add-insuccessfully managed to find all of the 281 todos tracked bythe Task List. This result shows that the tracking of todosworks in our add-in for the tested scenario.

5.2 Prototype Evaluation StudyIn the second study, we wanted to evaluate our prototypewith developers who use it in their day-to-day work. Twomaster students from the University of Zurich volunteeredto use the prototype during two workdays. Both have mul-tiple years of development experience, both in industry andacademia. They are currently working on a half-year projectwith a codebase of over 3,000 lines of code. To start theevaluation, we asked the participants a couple of questionsabout their current use of todos and theTask View. We alsowanted to find out if they ever created an item on TFS based

2http://pytools.codeplex.com

8/22/2019 Extended Todos

4/5

on such a todo. Subsequently, the add-in was installed onthe participants laptops and they were both given a shortintroduction into the goals, features and limitations of theprototype. They then started their normal workday. Asthe second author of this paper is also working in the sameproject, they could always ask some questions if needed. Inthe end of the first day, they were asked a couple of ques-tions with early feedback about the tool and how they used

it. At the end of the second workday, they participatedin a semi-structured interview consisting of a set of prede-fined questions. The questions referred to the usage of thetool, helpful and frustrating aspects and the influence ofthis tool on their work. The results are presented in thefollowing paragraph. Citations of the participants answerswere translated from Swiss German to the English language.

Being asked about how they use the Task List, both partic-ipants stated that they have never used it. S1 did not knowit existed. However, both participants are familiar with an-notations in code (i.e. todos) and regularly use them. Theyusually use todos during their own development to remindthemselves of tasks before they do a commit. S1 also createsa quick todo of what he is currently working on in case of aninterruption to help him get back to work faster. S2 findsthem powerful because they are fast and easy to create,but unpurified as they usually get lost in the code. Theyboth stated, that it sometimes was difficult to go back andfind todos if they could not remember, which todo they pre-viously created. S1 stated that he used the search until nowto find todos again. However, this was cumbersome, as hedid not always remember the exact wording of the todo. S2who tried the Task Listbut considered it to be not valuableenough to use it, wished to have a view that offered moreinformation about those todos. Besides the already presentinformation, the view should include information about thecreator and the creation date. He would also like to havethe possibility to filter the view to see only the todos he cre-

ated. Both participants would love to extract a work itemfrom a todo, as long as it would only require a minimum ofadditional effort. Without b eing explicitly asked, S2 statedhe would love to assign a todo to another developer.

At the end of the first workday, S1 created two todos anduploaded one to the TFS, whereas S2 created two todos aswell without exporting one to the server. According to S1,the view offers a great overview of all the todos and is ar-ranged very well. He really likes being able to assign a todoto others and to see the creator of a todo. S2 plans to workon his todos the second workday and hopes to create anitem on TFS then. In his opinion, the tool is a valuableaddition that offers much-needed features without losing its

lightweight nature. In one case, the pop-up appeared a littlebit too fast and before he finished writing a todo. He thenrealized that he could also conveniently edit the todo in thepop-up. S1 did not like the login process to TFS, as he hadto login two times to start his work; once for the TFS add-in and again for our prototype. Finally, S2 found out thattodos created in cshtml-files are not recognized and tracked.The same behavior can also be found in the original TaskListtool. We plan to address this issue in a future releaseof the tool . The participants responses from the secondday were again very encouraging. Both participants contin-ued using the tool on day two and again created a couple

of todos and items on tfs. S2 created a code review requestusing our tool - his first one in his programming experience.Both participants agreed on the tool being very intuitiveand easy-to-use. In the new view, S2 appreciated the filterto see only the todos assigned to him, as he decided to workthrough the todo list for two hours. He liked the view asit simplified to focus on his tasks. Both participants alsoagreed in the added benefit of the possibility to assign a

todo to a teammate and knowing the creator of the todo aswell as when it was created. Besides some minor bugs theydetected, they really liked the tool. The only frustrating ex-perience they had were some merging conflicts, somethingwe already planned to address in a future version of the tool(see Section 4). Both participants were not disturbed by thepop-up at all, but again mentioned that it sometimes wasshown in a short typing pause when they were still writ-ing the todo. However, as the todo could be changed inthe pop-up as well, they did not consider it as a problem.S1 mentioned that users possibly get used to it and might

just type todo and wait for the pop-up to appear to in-sert the other information. The participants also liked thatthe tool presents aggregated information to a todo and thepossibility to edit it. In the pop-up, they would like to havethe current iteration path selected by default. According toboth participants, the biggest added value is the possibilityto instantly create a work item from a todo. They like thatit is immediately integrated into their agile planning tool onTFS and reminds them to work on it. In addition, the viewhelps raising awareness of small open tasks and encouragesS2 to reserve time to deal with his todos. S1 thinks that thistool could lead to a behavior change in a different context,as developers now suddenly feel responsible for their todosbecause of the creator and assignee properties. According tohim, this would probably lead to even less todos and highermotivation to work with increased self-discipline and writebetter code. Finally, both participants mentioned that theycould not use the tool as much as they wanted but would

be interested to further use it if it was further improved. Incase it would be implemented, they suggested to improvethe merging and adding editing functionality to the grid inthe view, something we previously discussed as future work.

Generally, the results of the evaluation are very positive.However, these results cannot be generalized as a possiblelimitation to the encouraging feedback could be the fact,that the six interviews were conducted with only two devel-opers using the tool two workdays each. These developersare from the same population, master students who work ondevelopment projects besides their studies. Nonetheless, weconsider this as sufficient to get some useful early insightsinto the benefits, drawbacks and the great potential of the

approach. It would be very interesting to conduct anotherstudy with more participants, a polished prototype and overa longer period in order to test if the approach can reallyhelp developers in their daily work.

6. RELATED WORKAs previously described, the default behavior in todays IDEsis limited to the simple creation of a todo and visualizing itin a table, without any additional information. This limitedfunctionality can be found in Visual Studio, Eclipse and In-tellijIdea. However, there are already a couple of add-insand tools available that extend the IDEs default behavior.

8/22/2019 Extended Todos

5/5

ToDo Manager3 is a Visual Studio add-in to manage todos(filtering), prioritize them and add other information such ascode snippets or budgeted time to implement. Even thoughit is easy to use, it builds another database on top of theproject and is quite overloaded. In addition, it offers noconnection between the todo list and a planning tool. My-lyn4, a very successful Eclipse plug-in, creates a task-focusedinterface to manage a developers task and integrates them

into the work item or bug repositories. Both tools makeno use of the information that is available from the context(comment, code, author, etc.). Jira5 is an issue trackingand project management product. It offers some powerfulbut still easy to use functionality to perform queries on todolists. It also connects developers, other planning tools andthe source code repository. However, we found no connec-tion to todos in the code. CodeNotes6 is a very new tool thatintegrates into GitHub and allows the collaboration withother developers from the same source code repository viatodos. Unfortunately, it is currently not finished and avail-able for testing and only offers web access, which causes theburden to switch from the IDE to the browser to managetodos. Finally, Webstorm7 is a full-featured JavaScript IDEthat offers extended functions to manage todos, such as fil-tering, sorting or code preview to maintain a todos context.It lets the user also specify a set of patterns that can laterbe used in the filtering and sorting. However, it is rathercomplicated to use and offers no integration into the workitem or bug repository.

7. DISCUSSIONWhen we developed the extended todos approach and proto-type, we were left with several decisions to make. On the onehand, the approach should keep the lightweight characteris-tics of current todos but extend the very limited possibilitiespresent in current modern IDEs. Moreover, the approachshould be easily deployable, intuitive to use and should not

disturb a developer in his coding routine. This is why weimplemented our approach as an add-in. This add-in offersthree ma jor advantages over the present implementation oftodos in modern IDEs and the other tools presented in therelated work section. Those are the automatic inference ofadditional information of a todo based on the context, theconnection of todos to the agile planning tool and a newview including all additional information and new optionsto filter and sort todos. We gained very encouraging feed-back about this approach and its implementation throughour preliminary studies. The operability study helped usimproving our approach during the implementation processand validating the correctness of the tracking. The two par-ticipants in the prototype evaluation study appreciated the

connection to their Team Foundation Server the most. How-ever, the results of this study have to be taken with cautionas it was only conducted during two workdays with two de-velopers. It remains to future work, to polish some featuresof the approach such as the timing of the pop-up, editing to-dos in the view and updating todos between the add-in andTFS. Moreover, it would be interesting to conduct a bigger

3http://jaxcoder.com/Products.aspx?id=44http://www.eclipse.org/mylyn5https://www.atlassian.com/de/software/jira6http://codenotes.clojurecup.com7http://www.jetbrains.com/webstorm

study, including more developers over a longer period, tofind out how well the presented approach fits into a devel-opers life compared to the current IDE implementation andif the todos lightweight characteristics can be retained.

8. CONCLUSIONSThis paper introduces a new approach to increase the lim-ited representation of todos present in modern IDEs. Even

though their lightweight nature makes todos easy and com-fortable to use, it results in that developers easily lose sightof them. Our approach connects todos with the Team Foun-dation Server, a popular agile planning tool and enhancesthe default Task View by showing more relevant informa-tion and filtering, sorting and searching functionalities. Ourmain goal was to retain the lightweight characteristics of to-dos. Following the implementation phase, we performed twosmall-scaled studies to verify the add-ins operability andevaluate its usability with two developers. They providedus with rich, constructive and highly encouraging feedback.Furthermore, they made valuable suggestions for future ex-tensions and improvements, which we summed up in thesections of the prototype and the evaluation. Finally, it is

worth to note that our approach, despite its prototypicalcharacter exposed great potential, which is an interestingtopic for future research.

9. ACKNOWLEDGMENTSWe would like to thank the two participants for taking partin the evaluation of our prototype of the extended todosapproach. Help of Prof. Thomas Fritz and Katja Kevicbefore, during, and after the evaluation has also been greatlyappreciated.

10. REFERENCES[1] C. Parnin and R. DeLine. Evaluating cues for resuming

interrupted programming tasks.Proceedings of the 28th

international conference on Human factors incomputing systems - CHI 10, page 93, 2010.

[2] J. Ryall. Reminding and Refinding : Examining howSoftware Developers use Annotations by Reminding andRefinding : Examining how Software Developers useAnnotations by. PhD thesis, University of Victoria,2008.

[3] S. Sen, S. K. Lam, A. M. Rashid, D. Cosley,D. Frankowski, J. Osterhouse, F. M. Harper, andJ. Riedl. Tagging, Communities, Vocabulary, Evolution.Proceedings of the 2006 20th anniversary conference onComputer supported cooperative work - CSCW 06,page 181, 2006.

[4] M.-a. Storey, J. Ryall, J. Singer, D. Myers, and

M. Muller. How Software Developers Use Tagging toSupport Reminding and Refinding. IEEE Transactionson Software Engineering, 35(4):470483, July 2009.