Extended Todos

Improving the representation and management of code annotations without losing their lightweight characteristics.
Claudio A. Anliker
Department of Informatics, University of Zurich Binzmuehlestrasse 14 Zurich, Switzerland

Andr N. Meyer
Department of Informatics, University of Zurich Binzmuehlestrasse 14 Zurich, Switzerland

claudio.anliker@uzh.ch

andre.meyer@uzh.ch

1.

ABSTRACT

It is common practice that developers use task annotations in their code to improve its readability and the communication between team-members. Their fast creation makes them easy to forget, as there is usually no connection to a planning tool and only a limited view to manage them available. We introduce a new approach by connecting task annotations with an agile planning tool, improving their representation by adding contextual information and extending their default view. This approach aims to extend the very limited possibilities present in current modern IDEs such as Visual Studio, but also to keep the lightweight characteristics. An operability study and a small-scale evaluation shows the approachs great potential, despite its prototype nature and many possibilities and ideas for future work.

2.

INTRODUCTION

Program comments are often used as a common practice for improving code readability and the communication between 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 task annotations to write small, lightweight side notes into their code. This side note may serve a developer as a reminder of a future task, such as duplicated code, a small bug, a possible optimization or a reference check. The power of those task annotations, from now on referred as todos, is the very simple and quick creation of a new item as described in [2]. Without ever leaving the editor window, the developer can create a new todo by typing //TODO: ... (or something similar, depending on the programming language and the IDE). Some IDEs have a predened, often extensible set of keywords to be used. For example, Visual Studio oers developers the keywords TODO, HACK, and BUG per default. Todos usually do not contain a lot of information about their reproduction. Sometimes, they look as short as HACK: do properly later or TODO: Add new button here. This

missing context makes it dicult to complete them and to understand the reason for their creation. In some cases, it could make sense to extract a new work item or bug from a todo and store it in the planning tool. However, this step is time consuming and requires the developer to leave the current editor window. With the todo not being stored in the planning tool, it fails to remind developers and managers about tasks that need to be performed [3]. As soon as a todo is extracted as an item into the planning tool, it can be integrated in the normal planning cycles, such as the scrum meeting in an agile project. Modern IDEs, such as Eclipse or Visual Studio, aggregate todos and list them in a separate view. This list grows fast and it is dicult to keep an overview and the context of the lists items. Those views only oer limited possibilities to lter, sort and search those todos. This makes the yet powerful todos a possible threat to the success of a software project. They might be forgotten as the application relies on open issues. These issues could not only be some possible stability or performance optimizations, but also break the system and its maintainability. We consider it as highly desirable to improve the representation of these todos and make their management more powerful. Based on these reasons, we state the following research question: RQ: Can we nd an intuitive and easily deployable approach to improve the representation of todos and make them more powerful in a team-project without losing their lightweight characteristics? Our research question focuses on a new approach that extends the present and well-established concept of todos. To achieve this, we aim to integrate the rudimentary todoconcept of a popular IDE with a planning tool. Additionally, we want to provide developers with an extended and more feature-rich view, by letting them lter, search and sort todos and showing more relevant information. We expect this to simplify the management of responsibilities and the assignment of tasks among team members tremendously. Our approach is aimed to be simple and intuitive and retain the todos lightweight characteristics and simple creation. This paper is structured as follows. Section 3 describes the approach. Section 4 presents the prototype, some details about its implementation and ideas for future versions of the tool. Section 5 presents the results of two preliminary studies. The prototype is then compared to other similar tools

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

3.

APPROACH

The main goal of our project is to provide a tool to simplify the management and maintenance of todos and connect them to the teams planning tool. To achieve this goal, we have to provide the user with an extended representation of the todo by adding contextual information such as the creator, creation date, and assignee. We intend to further extend the described rudimentary todo concept by connecting the todos to a planning tool to share todos with co-workers. We expect this to simplify the management of responsibilities and the assignment of tasks among team members tremendously. In addition, the quality of the software might increase as the implementation of the todos can be planned and is not forgotten. Our approach is aimed to add this functionality without harming the todos lightweight characteristics and keeping it simple and intuitive. Integrating todos into a planning tool is not straightforward as it enriches them with new information, which might bring the risk of reducing their lightweight structure. Agile planning tools such as Microsofts Team Foundation Server (TFS)1 require additional information to create new work items, bugs, feature requests or code review requests. Some of this information, such as the current iteration path or the creator of the item, could automatically be inferred from the context. If developers have to provide this kind of data manually each time they create a new item on TFS, the usability of the approach would suer and developers would not have a benet in creating items directly from todos. Therefore, the tool should simplify this process by auto-completing as much information as possible and reducing user input to a minimum. The dierent purposes of todos do not always require them to be stored in the planning tool. Todos should still be as easy to create as before, regardless of the changes of our approach. Therefore, we have to ask the user as soon as he writes a todo if he wants to export it or just keep it locally as a standard todo. This could be achieved with a pop-up dialog, containing prelled contextual information to simplify the export to the planning tool if the user desires. To benet of the additional data of our todos, we want to supply the users with a new view, which shows them relevant information. As the information a developer might want to see is individual, users should be able to customize the view. This customization can be achieved by a lter and search functionality and a reasonable default selection of information to be shown. Finally, we want to extend the predened set of keywords used for a todo to let the user easily specify the type of item that is created on TFS. The reason for this extension is, that meaningful customized annotations can make tasks, such as organization and rending of todos, easier for the individual developer [2]. You may nd the mapping of the todo types to the types on TFS in Table 1. As an example, if the user
1

Extended Todo Keywords TODO HACK WTF CHECKME BUG TOCREATE NOTE

Item created on TFS Work Item Code Review Request Bug Feature Request nothing

Table 1: Mapping of the dierent types of todos to the items created on TFS. writes something like TOCREATE: create a delete button here, our add-in will ask the developer if he wants to save the todo as a feature request on TFS.

4.

PROTOTYPE

The implementation of our approach is an add-in for Microsofts IDE Visual Studio, which integrates with the version control and collaboration environment Team Foundation Server (TFS). The add-in is programmed with the Windows Presentation Foundation (WPF) framework (version 4.5). At startup, it shows a prompt to login to the TFS. This is required to connect todos to TFS. It is worth to mention that Visual Studio provides a way to create a new TFS work item itself. However, the interface is very heavyweight, asking for lots of information and is further not connected to todos in any way. Using our add-in, the process of creating an item from a todo on TFS is highly simplied and happens as follows: As soon as a todo is created, the add-in opens a pop-up window as briey discussed in the previous section. This pop-up is designed to be both lightweight and complete, which is why it provides the possibility to modify any information related to the todo. The information, which we consider less likely to be changed from its referred values is hidden behind an expander control by default. The pop-up window is shown in Figure 1. The discard button of the pop-up is focused by default, such that a single toggle of the enter key (or Alt+D) cancels the export. Similarly, the user can trigger the upload to the TFS very fast using the key combination Alt+S. The text boxes in the pop-up are editable and every change is automatically transferred to the code to provide consistency. The view of our add-in uses a DataGrid and allows dynamically showing or hiding columns as the user desires. Furthermore, DataGrids allow reordering columns to t the individual developers requirements best. We implemented the lter functionality using a combination of a textbox to add a text pattern and a dropdown to select a specic column to search for pattern matches, whereas by default all columns are selected. The extended todos view is shown in Figure 2. Our implementation has potential for improvements, which is inherent in its prototypical nature. A long-term project to enhance the tool could especially improve the usability.

4.1

Possible Improvements

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

A signicant limitation of our implementation is that Visual Studio does not provide a unique ID for todos. Since properties such as line number, assignee and description can change over time, they are not suitable to be used as an

ID. Unfortunately, creating an ID is inevitable to maintain the set of todos. The only way to bind the ID to the corresponding todo was to write it in the code. Since this ID is also reused as a marker if a todo is already incorporated to the add-in, every todo gets an ID, independently if it is exported to TFS or not. Initially, it was planned to store all the additional information concerning a todo outside the code in a separate le and reference to it via the global ID. However, this approach caused merging issues with version control as soon as dierent users added todos into the same source le. Therefore, we decided to write all of the information into the source le to avoid additional merging conicts, which are not directly related to code and have to be hidden from the developer anyways. This tradeo will be addressed in future work as the additional data corresponding to the todos pollutes the source code. A solution to this problem would increase the tools usability tremendously. Another potential improvement concerns the synchronization between todos and the TFS items. In the current implementation, the TFS and our add-in are not tightly coupled, as changes are not immediately reected on TFS and the other users views. This is a desirable optimization for a future implementation. Additionally, the items created on TFS could be further enriched with information about the source code context in which they were created. Another idea for future work is to consider hiding the todos in the source code, as it is discussed in the work by Parnin et al. [1]. The todos would still be tracked and shown within the view, but they are not shown in the .cs -les to keep the code clean. Nevertheless, this suggestion does not correspond to the nature of task comments as todos are called in the Visual Studio domain. Therefore, an accurate evaluation of this feature is inevitable to make a prediction on its usability. The view could benet from further improvement too as it is limited to a DataGrid, whose structure is very similar to Visual Studios task list. For example, the view could be improved with a treeview to group todos, e.g., by le, assignee or sprint number to provide a further presentation possibility. To keep the possible improvements and future work suggestions collocated, we anticipate here an input formulated by the participants of our study, which is presented in the following section. Generally, the participants mentioned many of the ideas we already noted for future work. This gave us good condence in our own interpretation of the approachs implementation. Additionally, they made one major suggestion. They think it would be a nice improvement of the view if developers could modify the todos by clicking on the corresponding row in the view, with automatic changes in the source code and on the TFS.

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 lter, sort and search for todos and shows more relevant information.

5.1

Operability Study

During the development of the prototype, we used our own add-in to make sure it works as intended and meets our goals. This heavily inuenced the nal version, as we were able to nd issues and complicated or not intuitive processes at early stages. This also made it possible to use the prototype in early stages of development to nd out how usable it is in a real-world software project and how we would work with it. As the foundation of the add-in is the correct tracking of the todos in the users code, we run a small operability study to determine if the tracking is working as expected. To do this, we used the most downloaded open source project from Codeplex and compared the number of todos shown in the original Task List view in Visual Studio with the number of todos our add-in found. The examined tool is called Python Tools for Visual Studio2 and is based on more than 249,000 lines of code and text. Our add-in successfully managed to nd all of the 281 todos tracked by the Task List. This result shows that the tracking of todos works in our add-in for the tested scenario.

5.2

Prototype Evaluation Study

5.

EVALUATION

Following the implementation of the prototype, we ran two preliminary studies to determine if the prototype works correctly and to get early feedback from two potential users of the tool. The results of the studies are presented in this chapter.

In the second study, we wanted to evaluate our prototype with developers who use it in their day-to-day work. Two master students from the University of Zurich volunteered to use the prototype during two workdays. Both have multiple years of development experience, both in industry and academia. They are currently working on a half-year project with a codebase of over 3,000 lines of code. To start the evaluation, we asked the participants a couple of questions about their current use of todos and the Task View. We also wanted to nd out if they ever created an item on TFS based
2

http://pytools.codeplex.com

on such a todo. Subsequently, the add-in was installed on the participants laptops and they were both given a short introduction into the goals, features and limitations of the prototype. They then started their normal workday. As the second author of this paper is also working in the same project, they could always ask some questions if needed. In the end of the rst day, they were asked a couple of questions with early feedback about the tool and how they used it. At the end of the second workday, they participated in a semi-structured interview consisting of a set of predened questions. The questions referred to the usage of the tool, helpful and frustrating aspects and the inuence of this tool on their work. The results are presented in the following paragraph. Citations of the participants answers were translated from Swiss German to the English language. Being asked about how they use the Task List, both participants stated that they have never used it. S1 did not know it existed. However, both participants are familiar with annotations in code (i.e. todos) and regularly use them. They usually use todos during their own development to remind themselves of tasks before they do a commit. S1 also creates a quick todo of what he is currently working on in case of an interruption to help him get back to work faster. S2 nds them powerful because they are fast and easy to create, but unpuried as they usually get lost in the code. They both stated, that it sometimes was dicult to go back and nd todos if they could not remember, which todo they previously created. S1 stated that he used the search until now to nd todos again. However, this was cumbersome, as he did not always remember the exact wording of the todo. S2 who tried the Task List but considered it to be not valuable enough to use it, wished to have a view that oered more information about those todos. Besides the already present information, the view should include information about the creator and the creation date. He would also like to have the possibility to lter the view to see only the todos he created. Both participants would love to extract a work item from a todo, as long as it would only require a minimum of additional eort. Without being explicitly asked, S2 stated he would love to assign a todo to another developer. At the end of the rst workday, S1 created two todos and uploaded one to the TFS, whereas S2 created two todos as well without exporting one to the server. According to S1, the view oers a great overview of all the todos and is arranged very well. He really likes being able to assign a todo to others and to see the creator of a todo. S2 plans to work on his todos the second workday and hopes to create an item on TFS then. In his opinion, the tool is a valuable addition that oers much-needed features without losing its lightweight nature. In one case, the pop-up appeared a little bit too fast and before he nished writing a todo. He then realized that he could also conveniently edit the todo in the pop-up. S1 did not like the login process to TFS, as he had to login two times to start his work; once for the TFS addin and again for our prototype. Finally, S2 found out that todos created in cshtml -les are not recognized and tracked. The same behavior can also be found in the original Task List tool. We plan to address this issue in a future release of the tool . The participants responses from the second day were again very encouraging. Both participants continued using the tool on day two and again created a couple

of todos and items on tfs. S2 created a code review request using our tool - his rst one in his programming experience. Both participants agreed on the tool being very intuitive and easy-to-use. In the new view, S2 appreciated the lter to see only the todos assigned to him, as he decided to work through the todo list for two hours. He liked the view as it simplied to focus on his tasks. Both participants also agreed in the added benet of the possibility to assign a todo to a teammate and knowing the creator of the todo as well as when it was created. Besides some minor bugs they detected, they really liked the tool. The only frustrating experience they had were some merging conicts, something we already planned to address in a future version of the tool (see Section 4). Both participants were not disturbed by the pop-up at all, but again mentioned that it sometimes was shown in a short typing pause when they were still writing the todo. However, as the todo could be changed in the 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 insert the other information. The participants also liked that the tool presents aggregated information to a todo and the possibility to edit it. In the pop-up, they would like to have the current iteration path selected by default. According to both participants, the biggest added value is the possibility to instantly create a work item from a todo. They like that it is immediately integrated into their agile planning tool on TFS and reminds them to work on it. In addition, the view helps raising awareness of small open tasks and encourages S2 to reserve time to deal with his todos. S1 thinks that this tool could lead to a behavior change in a dierent context, as developers now suddenly feel responsible for their todos because of the creator and assignee properties. According to him, this would probably lead to even less todos and higher motivation to work with increased self-discipline and write better code. Finally, both participants mentioned that they could not use the tool as much as they wanted but would be interested to further use it if it was further improved. In case it would be implemented, they suggested to improve the merging and adding editing functionality to the grid in the 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 possible limitation to the encouraging feedback could be the fact, that the six interviews were conducted with only two developers using the tool two workdays each. These developers are from the same population, master students who work on development projects besides their studies. Nonetheless, we consider this as sucient to get some useful early insights into the benets, drawbacks and the great potential of the approach. It would be very interesting to conduct another study with more participants, a polished prototype and over a longer period in order to test if the approach can really help developers in their daily work.

6.

RELATED WORK

As previously described, the default behavior in todays IDEs is limited to the simple creation of a todo and visualizing it in a table, without any additional information. This limited functionality can be found in Visual Studio, Eclipse and IntellijIdea. However, there are already a couple of add-ins and tools available that extend the IDEs default behavior.

ToDo Manager3 is a Visual Studio add-in to manage todos (ltering), prioritize them and add other information such as code snippets or budgeted time to implement. Even though it is easy to use, it builds another database on top of the project and is quite overloaded. In addition, it oers no connection between the todo list and a planning tool. Mylyn4 , a very successful Eclipse plug-in, creates a task-focused interface to manage a developers task and integrates them into the work item or bug repositories. Both tools make no use of the information that is available from the context (comment, code, author, etc.). Jira5 is an issue tracking and project management product. It oers some powerful but still easy to use functionality to perform queries on todo lists. It also connects developers, other planning tools and the source code repository. However, we found no connection to todos in the code. CodeNotes6 is a very new tool that integrates into GitHub and allows the collaboration with other developers from the same source code repository via todos. Unfortunately, it is currently not nished and available for testing and only oers web access, which causes the burden to switch from the IDE to the browser to manage todos. Finally, Webstorm7 is a full-featured JavaScript IDE that oers extended functions to manage todos, such as ltering, sorting or code preview to maintain a todos context. It lets the user also specify a set of patterns that can later be used in the ltering and sorting. However, it is rather complicated to use and oers no integration into the work item or bug repository.

study, including more developers over a longer period, to nd out how well the presented approach ts into a developers life compared to the current IDE implementation and if the todos lightweight characteristics can be retained.

8.

CONCLUSIONS

This paper introduces a new approach to increase the limited representation of todos present in modern IDEs. Even though their lightweight nature makes todos easy and comfortable to use, it results in that developers easily lose sight of them. Our approach connects todos with the Team Foundation Server, a popular agile planning tool and enhances the default Task View by showing more relevant information and ltering, sorting and searching functionalities. Our main goal was to retain the lightweight characteristics of todos. Following the implementation phase, we performed two small-scaled studies to verify the add-ins operability and evaluate its usability with two developers. They provided us with rich, constructive and highly encouraging feedback. Furthermore, they made valuable suggestions for future extensions and improvements, which we summed up in the sections of the prototype and the evaluation. Finally, it is worth to note that our approach, despite its prototypical character exposed great potential, which is an interesting topic for future research.

9.

ACKNOWLEDGMENTS

7.

DISCUSSION

When we developed the extended todos approach and prototype, we were left with several decisions to make. On the one hand, the approach should keep the lightweight characteristics of current todos but extend the very limited possibilities present in current modern IDEs. Moreover, the approach should be easily deployable, intuitive to use and should not disturb a developer in his coding routine. This is why we implemented our approach as an add-in. This add-in oers three major advantages over the present implementation of todos in modern IDEs and the other tools presented in the related work section. Those are the automatic inference of additional information of a todo based on the context, the connection of todos to the agile planning tool and a new view including all additional information and new options to lter and sort todos. We gained very encouraging feedback about this approach and its implementation through our preliminary studies. The operability study helped us improving our approach during the implementation process and validating the correctness of the tracking. The two participants in the prototype evaluation study appreciated the connection to their Team Foundation Server the most. However, the results of this study have to be taken with caution as it was only conducted during two workdays with two developers. It remains to future work, to polish some features of the approach such as the timing of the pop-up, editing todos in the view and updating todos between the add-in and TFS. Moreover, it would be interesting to conduct a bigger
3 4

We would like to thank the two participants for taking part in the evaluation of our prototype of the extended todos approach. Help of Prof. Thomas Fritz and Katja Kevic before, during, and after the evaluation has also been greatly appreciated.

10.

REFERENCES

[1] C. Parnin and R. DeLine. Evaluating cues for resuming interrupted programming tasks. Proceedings of the 28th international conference on Human factors in computing systems - CHI 10, page 93, 2010. [2] J. Ryall. Reminding and Rending : Examining how Software Developers use Annotations by Reminding and Rending : Examining how Software Developers use Annotations 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, and J. Riedl. Tagging, Communities, Vocabulary, Evolution. Proceedings of the 2006 20th anniversary conference on Computer 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 to Support Reminding and Rending. IEEE Transactions on Software Engineering, 35(4):470483, July 2009.

http://jaxcoder.com/Products.aspx?id=4 http://www.eclipse.org/mylyn 5 https://www.atlassian.com/de/software/jira 6 http://codenotes.clojurecup.com 7 http://www.jetbrains.com/webstorm