This blog post was originally posted on The ICSE 2011 Workshops Blog.
Arie van Deursen‘s Pollicino introduces a new notion of bookmarks in Eclipse: bookmarks are viewed as breadcrumbs or stones, showing paths through the maze of code. I have used bookmarks not to get lost in difficult programming tasks; however, I delete the bookmarks after finishing the task, because the existing bookmarks would confuse me in my next task. What a waste of valuable information! Pollicino can organize that for me, show paths through the code, and share this information. And I think, with some enhancements, it can be even more than this.
I work with different teams of software developers, and all of them need something like a developers’ knowledge base, but no one has a convincing solution. Some use wikis, some use special tools, and when such solutions are implemented, some developers are enthusiastic about it, provide content, and look for information to solve their programming problems. But in the long run, programmer don’t contribute, and they don’t search in the knowledge base. They even forget that it exists. Here Pollicino can come into play: It records traces from problems to the relevant parts of the code. That’s exactly what we need. So if we make this information searchable, share it in a database, add some structuring information (categories, tags, semantics, …), and sort of a Q&A web interface, we can make this an essential part of the development infrastructure.
The data collected by Pollicino will be very interesting to analyze using data mining tools. We could learn a lot about improving the development process, removing obstacles, identifying hot spots, how the code is related to use cases and bugs, …
Another demo I want to mention is Automatic Status Updates in Distributed Software Development by Abayomi King from the University of Toronto, also an Eclipse plugin. It sets a developer’s IM status depending on what he or she is doing, so the developer can select tasks and activities where he or she does not want to be disturbed. This also solves the problem than often people forget to unset their busy status. The focus of the demo was to control interruptions, keep the busy status up to date, and inform other team members about what one is doing.
I’d like to add one point: interruptions through IM messages, Skype calls, email popups, twitter, etc. have an impact on focus and productivity. Each interruption moves our focus to an incoming email for example, even if we decide to ignore it. It takes some time to re-focus on the original task. And even worse, you have no chance to get into deep focus, a focus you need to carefully analyze difficult problems. So I think we should extend the scope of such a tool to all interrupters and then conduct research about the productivity and quality impact of an interruption-aware working style.
Did you ever try to teach collaborative programming to undergraduate students? Impossible to do until you know Wikigramming by Takashi Hattori from Keio University. The idea is to program Lisp in a wiki, where each function is a wiki page. Each function can have unit tests attached of the functions it uses. That’s interesting. Function authors can write down what they expect from other functions others might modify.
I think it should be possible to make students develop a program collaboratively and highly parallel using this wiki-style of programming. The collaborative experience will be very interesting I guess. And, as a side effect, I hope that people understand the power and composability of purely functional programming.
Thanks for the organizers for making such a great and collaborative workshop!