The Third Bit

Pursuant¹ to last week’s post on making tickets simpler to work with in DrProject, I’m now wondering whether the real problem isn’t the number of fields, but the fact that the only way to file a ticket is through a web browser. If you’re grinding away in Eclipse (or Notepad) and want to add a note to your project, you have to:

1. Click on “Favorites”
2. Click on the link to your project
3. Enter your user ID and password (since your previous session has almost certainly timed out)
4. Click on “New Ticket”

and then jot down whatever it was you wanted to jot down. Of course, by this point you’ve lost your original train of thought…

Simplifying the interface isn’t going to solve this problem (as Alastair Cockburn says in his latest book, “Efficiency is expendable in non bottleneck activities.”), though it wouldn’t hurt. And no, Andrey, lengthening the session timeout isn’t a real cure either . I applied for a grant to do a proper scientific study of impact things like the Mylar plugin for Eclipse (which provides an in-IDE interface to ticketing systems, among other things), and the Visual Studio plugin for FogBugz, would have, but IBM turned me down. If anyone is looking for a medium-sized project that’ll make ‘em rich, famous, and popular², please give me a shout…

[1] I’ve always wanted to use that word in a blog post…

[2] I lied about the ‘rich’ bit, but small-f famous and small-p popular are not entirely impossible…

DrProject

Here’s a draft proposal for modifying DrProject‘s ticketing system based on feedback from the post-mortem:

1. State is simply “open” or “closed”, and becomes implicit: the buttons to update a ticket are labeled “Preview”, “Update”, and “Close”.
2. Tickets can be assigned to roles, as well as to specific users, so that if an organization distinguishes “tester” from “developer”, tickets can be marked accordingly.
3. Get rid of “type”: if people want to distinguish different kinds of tickets, they can evolve a set of tags. (This is the same argument we used to get rid of the “component” field inherited from Trac.)

Still unsure what to do about actual and estimated effort: companies want it, but we know that student teams won’t use it (or that if they do, their numbers will be science fiction).  Is a “small/medium/large” pulldown when filing the ticket enough, if people can adjust it again when closing the ticket to show actual effort?

DrProject

Adam Goucher has answers.

Uncategorized

This, via Bruce Schneier: for US$250, you can build a device that will electronically track anyone using Nike’s latest toy-for-rich-people.

Uncategorized

A list of videos has been posted on the Google Research blog. Lots of good stuff here, including “How to Survive a Robot Uprising”, and Bil Lewis on reversible debuggers.

Uncategorized

Rebecca Wirfs-Brock‘s latest column in IEEE Software is titled “Explaining Your Design”.  She posits a hierarchy of importance in explanation:

• things you can’t change
• problem description and requirements
• things (entities)
• organizing structures
• the typical case
• concrete examples
• design principles

She also talks about the importance of story lines in explanations. It’s thought-provoking, particularly as we’re trying to think of requirements management and documentation components for DrProject.

Uncategorized

I recently started using Thunderbird as an email client, and while I like its interface, I’m not happy with its address book.  In particular, you can only save two email addresses per person (I have five right now, and many of my students have three or four), its tabbed display forces me to do a lot of extra clicking when entering information, and there doesn’t seem to be a “show new entries” capability.

I’m therefore looking for a better address book application.  It has to integrate with Thunderbird, and must not store addresses on a web site.  (I currently keep my address book in LDIF format under version control, so that I can keep the three machines I use regularly in sync.)  Any suggestions?

Uncategorized

As I mentioned earlier, I’ve put the review queue online. The latest additions are:

• Brian: Berkeley DB XML (Apress)
• Cockburn: Agile Software Development (Addison-Wesley)
• Cohoon & Aspray (ed): Women and Information Technology (MIT Press)
• Johnson: RSS and Atom in Action (Manning)
• Langville & Meyer: Google’s PageRank and Beyond (Princeton University Press)
• Ramm, Dangoor, & Sayfan: Rapid Web Applications with TurboGears (Prentice-Hall)
• Rappin & Dunn: wxPython in Action (Manning)
• Tutsch: Performance Analysis of Network Architectures (Springer)
• Wysopal, Nelson, Zovi, & Dustin: The Art of Software Security Testing (Addison-Wesley)

Books

We held a post mortem on this term’s projects Friday before going out to dinner. I took away three major points:

1. We have to simplify the ticketing interface in DrProject, so that people will use it even in very small groups. One suggestion is to make it more like Basecamp‘s to-do list. However:
• We want to keep AJAX to a minimum (accessibility, stability, etc.).
• Some of the companies who are thinking about adopting DrProject (or who have done so already) want to add complexity; in particular, they want parent-child and precedes-follows relations on tickets, a “ready for test” state, and so on.
2. Students think that doing demos is a valuable experience, but it takes a lot of time. (Students get to do their demos twice: once for feedback, and one for a grade.) Swapping them around—i.e., having one day’s students practice on their peers, then do their real demos for another day’s students—is one possibility, but scheduling is going to be difficult. We’ve also tried having students do their final demos in tutorial sections of sophomore courses, to give second-year students a taste of what they could be doing by final year, but again, scheduling is hard.
3. I didn’t track students’ progress nearly as well as I should have. There’s no amalgamated cross-project view in DrProject (yet—David Scannell has built it, but we haven’t deployed it on the production server), and while cycling through seven projects to check event logs isn’t that tedious, I somehow never quite got around to it. As a result, students didn’t structure their work around making the event log look good, which led to a downward spiral.

If we upgrade DrProject over the break, #3 will (mostly) take care of itself. I’m open to suggestions for #2, but what I’d really like from readers is ideas for #1.  We do not want a “kitchen sink” interface that relies on configuration files to hide certain features in certain installations; I know from personal experience that these are a nightmare to test and maintain.

Ideas?

DrProject, Teaching

It’s official: Jon Udell (the John McPhee of the Internet) is joining Microsoft. Why?  Because, “This isn’t your father’s—or maybe your older brother’s or sister’s — Microsoft. Initiatives like [several he describes] matter, they’re solidly in line with my own agenda, they’re being pursued in very open ways, and I want to help move them forward.”  So, congratulations and best wishes—I look forward to more years of informative, insightful discussion.

Uncategorized