Seeking opinions (and hopefully beta-testers) for a developer's memory aid I'm developing for my dissertation (Eclipse/Java)
-
Hi all.
Not sure this is the best forum for it, but it seemed more appropriate than the "general discussions" one.
As part of my my doctoral work I am developing a personal memory-aid for developers in Eclipse.The motivation behind this work is that a lot of problems are caused by the limitations of our memory: we become disoriented, we forget to follow up on our mental reminders, and we forget the correct protocols and ways to use a method that we wrote earlier.
My thesis is that if we can lower the knowledge capture costs and make the knowledge more available in relevant contexts, we can reduce these problems.
I am developing a personal memory-aid for Java developers in Eclipse. The tool lets you capture short notes via a series of popups; this is similar to a comment, except that it's not part of the code and therefore you don't need to edit it as well.
It then presents this information in two views. The first is a chronological view of your notes, interleaved with a record of your actions. So in a way, it extends your short term memory. You get interrupted or come back from lunch, and you can see your most recent activities and even what files were involved. (This is different from Mylar though complements it).
In the second view, it presents the notes in your current context (equivalent to what you would get with a comment), but also notes relevant to the current context. So that, for example, if you are looking at method foo(), which calls method bar(), and in bar() you have a remaining to-do, a bug, and a note about having to call another method first, you will know it without having to actually go and look at bar().
It's an early research prototype (i.e., not for production use), but I'm trying to find people who would be interested in giving it a spin.Any comments (and flames) on whether you think this might be useful or not would be appreciated as well.
You can see some screenshots at:
Thanks,
Uri
-
@uricmu said:
As part of my my doctoral work I am developing a personal memory-aid for developers in Eclipse.
The motivation behind this work is that a lot of problems are caused by the limitations of our memory: we become disoriented, we forget to follow up on our mental reminders, and we forget the correct protocols and ways to use a method that we wrote earlier.
First, defend the memory problem -- because I don't believe it's that troublesome -- and why a programmatic solution would be superior over simpler methods, such as a text file with a custom syntax-colouring definition in a text editor -- which is what I do.
It works for me, and I find nothing that I still need from it, but I'm open to the idea that my method might be Blub.
-
Were I doing any Java at the moment, I'd be willing to give it a spin. But I must ask -- and perhaps you explained this and I didn't follow -- how does this grant significant improvement over Eclipse's built-in Task Tags?
-
That's ok, I really didn't explain it right in the (very abbreviated) explanation I gave earlier.
First, the tool support not only tasks, but also any other notes and reminders one wishes to make, including, for example, assumptions and expectations of use. So you could leave a to-do, or leave a note indicating that anyone using your method must first invoke another method.
Second, part of the problem we are trying to solve is that of context. If you look at a heavily populated Eclipse task list, you'll notice that each entry (and especially ones originating in //Todos) was created in a certain context, and may contain deictic references to other things (e.g., "I have to finish this").or (e.g., "make sure this works even for a null"). This is different from bug reports where you usually try to write them nice and complete, but which are too expensive to produce for those smaller things. Anyway, so if you now look at just your plain task list, you may have difficulties interpreting what you actually intended to do. Your memory of the context is lost. This is true even if you have a to-do in the code. In my experience (and this is backed by a study from a different research group) most codebases include some old to-dos that nobody has an idea of what they're about and how they got there. What my tool does is that it preserves a lot of context about what you do. You coulld scroll back to the point in time where the to-do was created, and see what files were being edited (and what exact changes took place), so you might know "what to finish this" refers to. Prior to that to-do you might even encounter a note saying that the user was going to work on task X; you then know that "finish this" likely refers to task X. You get that traceability.
Third, one of the problems with to-do lists is that of saliency. You got all those to-dos in the list, but how are you going to aware of them when you're looking at the method or a method that uses it. If you used a //todo comment, you would have to inspect the source code. So when you're tying to figure out a bug and see a call from A to B, you may have no chance to know that there's something you forgot to finish in B, without actually inspecting B and seeing that note. If you just left an entry in the task list, or on another sheet of paper, you have to actually go and look for it, and there might be no reason for you to bother to do so when looking at A or B...
Uri.
-
@dhromed said:
First, defend the memory problem -- because I don't believe it's that troublesome -- and why a programmatic solution would be superior over simpler methods, such as a text file with a custom syntax-colouring definition in a text editor -- which is what I do.
It works for me, and I find nothing that I still need from it, but I'm open to the idea that my method might be Blub.
I get this question often when I describe this work, because every programmer has his established ways (until I started using my own tool, mine were different to).
Your question asked about reminders and tasks so I'll focus on that, though the memory aid helps with other things (orientaton, artifact use, etc.)
There are four problems with any mechanism for keeping reminders (and other relevant knowledge): cost, context, saliency.
Producing reminders or tasks involves a variety of costs depending on the medium use. You have to write the text and edit it (people spend more time on this if it is public, as in open source comments or bugzilla). You have to find a place for the text in a comment (not always trivial). You have to switch tools (e.g., web browser or notepad) or window (with built-in task lists or Mylyn). You have to provide enough context (e.g., in a bug report, what you were working on, and where). You have to resolve deictic references, etc. The higher the costs, the more likely you are to just say "screw it, I'll just try to remember it". So you will write down important tasks, some minor tasks, but if you're writing a method and think of two refactorings, something you didn't finish, and something you need to test, it's unlikely that you'll capture all four. And we do know from studies that part of what doesn't get written down gets lost.
The issue of context is also important, I explained it in the message above. Depending on how much you invested in creating your reminder, you may not be able to interpret it in the long run without remembering the exact context you created it in. If you look at one of your old reminder sheets, can you easily pinpoint the meaning in each?
The third issue is that of saliency. When do you become aware of the task? If it's in an external notepad, you will have to go and look at that notepad (and if it's a long list, you will have to scroll); similarly with Bugzilla. You're more likely to do this when you're looking for the next thing to do, than when you're actually coding. The problem is that a lot of these reminders matter while you're coding because people branch out a lot and yet have a lot of ad-hoc reminders. You could be working on method A, remember you need to finish something, 10 minutes later work on method B, make the call for A, and never remember you forgot to do something in B. It's true that if you have a to-do comment (I am guessing that's what you mean by a syntax-coloured definition?) and inspect the code of B, you'll know about it. But if you're just looking at A while you're debugging and it makes a lot of calls, are you going to look at the source code of all of them?
Hope this helps.
-
You make a reasonable case on some things, such as
@uricmu said:
And we do know from studies that part of what doesn't get written down gets lost.
100% correct. If I don't jot it down, it's gone, unless I happen to remember it the next day and then write it down.
@uricmu said:
It's true that if you have a to-do comment (I am guessing that's what you mean by a syntax-coloured definition?) and inspect the code of B, you'll know about it. But if you're just looking at A while you're debugging and it makes a lot of calls, are you going to look at the source code of all of them?
What I mean is that Editplus allows you to define a fresh new file type with a custom extension and custom colourable syntax items. :)
I have that .todo list in my start menu for quick opening. I have various comment colours for Done versus defer/delay/feedback and a couple of symbols to indicate addition, deletion or change. I don't think I'm using the syntax files to their full potential, though.
@uricmu said:
people branch out a lot
I don't. Or tend to avoid it as much as possible.
@uricmu said:
If you look at one of your old reminder sheets, can you easily pinpoint the meaning in each?
The old stuff gets deleted. The current stuff is also current in my mind.
Another detail of my way of working is that I do not, under any cicrumstances, leave "Todo" comments in the code -- precisely because of the 99% danger of forgetting. I'm assuming that your software targets this issue specifically and tries to turn it into a strength?
-
@dhromed said:
100% correct. If I don't jot it down, it's gone, unless I happen to remember it the next day and then write it down.
@uricmu said:
people branch out a lot
I don't. Or tend to avoid it as much as possible.
@uricmu said:
If you look at one of your old reminder sheets, can you easily pinpoint the meaning in each?
The old stuff gets deleted. The current stuff is also current in my mind.
Another detail of my way of working is that I do not, under any cicrumstances, leave "Todo" comments in the code -- precisely because of the 99% danger of forgetting. I'm assuming that your software targets this issue specifically and tries to turn it into a strength?
I think that branching is unavoidable in many cases, or merely the situations in which you realize there are two things you need to do (e.g., robustness and refactoring vs. continuing work); the branch is inherent in that you pick one and leave the other. Some tasks are just branching by nature. You know you are going to have a source, a destination, and a protocol for something, you have to branch by picking one.
Again, some of the stuff I said is based on a fairly elaborate study on how people deal with reminders during development, but there are naturally differences between individuals.The issue of to-dos in the code do make you relatively unique; most people leave at least some notes that way. However, it is a known phenomenon that people avoid //todos in the code, partly because the clutter it creates and partially because of bounded transparency (not wanting others to see their incomplete work or know how many things they haven't finished).
My tool offers an alternative to code to-dos. It costs no more (and actually less) than a to-do comment, but it's stored separately from the code. Hence, you don't worry as much about clutter, and you can see it in different ways. First, when chronologically looking at everything that you've done (and therefore have your to-do connected to the high-level modification request you were working on), and second, in other contexts than the method in which they appear. Either with external notes or with code to-dos, that would be a problem at least some of the time. If you leave a to-do in the code, you often has to actually read the code to know that it's there; with my approach, you're reminded of it while working on something relevant or something that depends on it.
-
@dhromed said:
What I mean is that Editplus [snip] various comment colours for Done versus defer/delay/feedback. :)
Now that sounds handy - could you mail me the .stx file?
-
@Benn said:
@dhromed said:
What I mean is that Editplus [snip] various comment colours for Done versus defer/delay/feedback. :)
Now that sounds handy - could you mail me the .stx file?It's nothing that fancy.
Some day I'll look into stx files but good. I have the idea that linecomment colours are limited to 2, which makes me sad.
And the stuff for setting.ini:
[Settings\Custom1]
Extension=todo
Description=Todo list
File=
Function=
Tab=3
Indent=3
Margin=80
Word Wrap=0
Auto Indent=1
Tab Indent=1
Common=0
Indent Open=0
Indent Close=0
End of Statement=0
Syntax file=C:\Program Files\EditPlus 212\todo.stx
Insert Space=1
Hard break=0
Wrap at Column=0
Show Marker=1
Column Marker 1=3
Column Marker 2=6
Column Marker 3=9
Column Marker 4=12
Column Marker 5=0
Column Marker 6=0
Column Marker 7=0
Column Marker 8=0
Column Marker 9=0
Column Marker 10=0
0=14507795
1=1807616
2=65995
3=14221529
4=128
5=9474192
6=221899
7=8421504
8=32768
9=16711935
10=16711935
11=8388736
12=8388736
13=8388736
14=8388736
15=8388736
16=8388736
Disable Auto-completion=0
Trim Trailing Spaces=1
uricmu_emoose_project
