Soapbox Rants and Raves

I recently wrote a post about how Eclipse helps to maintain the developer’s focus; what I really wanted to write about was the Mylyn plug-in.  I recently worked on a small project where we setup a completely open-source development environment, built on top of an Ubuntu Linux server. What made the environment interesting, was how well everything worked together. One of the more challenging issues working on a small project is the communication and task management; this is where Mylyn helps smooth out the process.

Mylyn is a simple Eclipse plug-in that integrates with a large number of commercial and open-source issue tracking systems. On the surface, it looks like any other tracking tool, but provides far more functionality than a simple web-based solution.  Building on my previous post, Emacs to Eclipse, the developer can conveniently manage their programming assignments without leaving Eclipse. It even has a notification system which alerts the developer to newly created or assigned tasks. I believe this approach is far more effective than relying on email or external applications to manage the development process.

What makes Mylyn unique, is that each task can be assigned a context. The context represents the state of the Eclipse session, maintaining a list of all of open files. The first step is for the developer to activate a task. Once activated, the developer has the ability to assign a context to that task.  From this point forward, as long as that task is active, the context will be kept in sync with all of the files that the developer opens.  If the developer chooses to activate a different task, the current task is deactivated and the new task is activated. The open files are automatically closed and the files linked with the new task are opened; even restoring the cursor position within the files.  The is extremely helpful when working on multiple, unrelated tasks which are being worked in parallel.

There are a variety of other subtle integrations that also improve the developer’s effectiveness:

• One of the more convenient features is the ability to create tasks from any “warning” or “TODO” comment. The developer just right clicks on the marker to generate the new task.
• Mylyn is also integrated with the Team Plug-in (SVN/CVS). It will automatically populate the commit message with the task information.
• Using the plug-in’s file upload functionality,  developers can easily attach supporting documentation (stack traces or generated files). There is even a built-in screen capture utility which allows the developer to grab, crop, and annotate images, which can be quickly attached to the task.
• Mylyn magically tracks the amount of time the developer spends working on a task. It appears to be the real time spent on the ticket (based on having Eclipse open and active, not simply based on when the ticket was opened and closed; pretty cool!). This could be very useful in Agile projects, comparing the estimated time to the actual time spent on the task. What a great way to help the developer to improve their future estimations.

The primary issue tracking tool where I work does not integrate with Mylyn. It would be nice if it did, but I don’t know how important that really is. I have been thinking about the integration of a secondary, fine grain task management tool into the environment that is more developer focused.  I actually think it would be interesting to have two issue tracking systems. The first system would be exclusively for the QA and production support teams, mainly to track defects discovered in testing or production related issues.  The second system would be used exclusively to manage the development process. Why create tens or hundreds of tickets in the real ticket tracking system, just for the development team to build the next release? The answer really depends on the scope or purpose of the ticket, but generally it is too much work to create task level assignments in real tracking system. I would really like the tickets in the development environment be more fluid and granular, actually representing the work that needs to be done, not an outdated, vague interpretation of what might happen during development cycle. If a create needs to be created for a developer to refactor a method or add a jUnit, no big deal.  If I’m using the real production ticketing system, I would need several levels of approvals, both from the business sponsor and test teams. Unfortunately, this impledes progress and the actual work being performed is of no interest to them anyway, it is just part of the normal development process. The bottom line is that I currently have no way to easily task or manage the development process or myself; it is currently done through email chains and some crude “TODO” comments in the code. Kind of a bummer when the technology exists, for free (minimal configuration time) and could actually be a huge benefit for the development teams. If you include the planning aspects of the tool, I could see this being a huge help for the project managers as well.

Unfortunately, because of the infrastructure requirements (mysql, tomcat, etc.) of the open source tools (bugzilla, trac, etc.), it is politically too difficult for teams to integrate in the corporate environment. I recently read about an interesting Mylyn connects that lets you store the tracking information in a relational database, rather than a full featured ticket tracking system. I have yet to explore this option, but it might open up the door for allowing me to utilize Mylyn, without the infrastructural overhead. I will keep you posted!