Warning: This post isn’t meant to be an exhaustive exploration of Mylyn for ColdFusion developers; rather, it’s a quick dive into why I love it and would not want to work without it.

What is Mylyn

Mylyn is an Eclipse plugin that works with both ColdFusion Builder and CFEclipse.

From the Mylyn home page:

“Mylyn is a task-focused interface for Eclipse that reduces information overload and makes multi-tasking easy. It does this by making tasks a first class part of Eclipse, and integrating rich and offline editing for repositories such as Bugzilla, Trac, and JIRA. Once your tasks are integrated, Mylyn monitors your work activity to identify relevant information, and uses this task context to focus the user interface on the task-at-hand. This puts the information you need at your fingertips and improves productivity by reducing searching, scrolling, and navigation. By making task context explicit Mylyn also facilitates multitasking, planning, reusing past efforts, and sharing expertise.”

For me, this means:

• Noise reduction
• Easy context switching and context reconstitution
• Easy “context sharing”

All of this happens in the context of “tasks”. This might be a bug, a new feature, etc. It’s great when you can hook it into an issue tracker like Jira or Trac, but Mylyn can work just as well without a formal issue tracker.

Let’s look at what that actually means.

How Mylyn benefits me as a CFML developer

Part 1: Noise Reduction through “context”

My main Eclipse workspace contains dozens of projects. I keep all projects closed except active projects. Even with only a single open project, the workspace contains hundreds if not thousands of files. Here’s a screenshot of the Project Explorer with me working on an MXUnit issue, with just that project active in my workspace:

As I’m developing, I probably only care about a few files at a time. But the project explorer doesn’t help me keep “just those files” in view.

This is the first problem Mylyn solves: it helps you keep all the files you care about in sight and hides the rest.

Here’s what that same screen looks like when I create a task for what I’m working on:

Notice how the project explorer now contains just the files I want to see. This is the context of the issue I am working on. As I open more files, they get added to the context. If I want, files can drop off of the context as I close them. Removing files from the context manually is a keyboard shortcut away (ctrl-alt-shift-downarrow).

Part 2: Context Switching and Context Reconstitution

I have no proof of this, but I’d bet that most developers – at least developers in a corporate environment – work on more than one issue at any one time. Perhaps you’re developing a feature, and you get an emergency bug that just has to be fixed right this second or oh my God we’re all gonna die. Perhaps you’re fixing a bug in some system and as you’re doing so, you stumble on a bug in another system that you need to fix first because it’s blocking your ability to fix the immediate bug you’re working on. Regardless of details, this “multi-tasking” appears to be common.

But I don’t think brains work that way. Brains can’t spawn threads that think about 5 things at once. You can’t be fixing one bug while simultaneously fixing the bug that’s blocking you from your immediate bug fix. We have not acquired such higher consciousness yet.  So no… we don’t multi-task.

We context-switch. Very very fast, in some cases.

The inevitable problem with context switching is that as soon as you stop working on Thing 1, and move on to Thing 2, the process begins whereby you forget stuff about Thing 1. You forget what code you were working on. You forget what you were thinking. You forget what other files were associated. The mental bonds you had constructed around that Thing begin to decay.

When you return to working on Thing 1, loading all of that data back into memory takes time. This is why programmers are always complaining to managers about “Stop/Start Time”. It’s why, when a PM fails to fully spec a problem, and the developer ends up working on the same thing 5 different times till it’s done right, that developer gets grumpy.

Imagine, though, if moving from one issue to another, and back again, was a simple matter of a menu selection.

Imagine:

1. You’re working on Thing 1. You have 8 files associated with it. Your PM comes running down the hall, crying and blathering about how “The client is going to leave us right this very second if we don’t fix (insert dumbass unimportant thing here)!”.
2. She enters a bug for Thing 2: “If website font isn’t shrunken by .0003 Pixels, Client will Leave and we’ll all foreclose on our houses”.
3. You close all the files you’re working on, you open up the appropriate files for this new bug. You save the day and the houses of your colleagues
4. You close those files, hit a button, and presto, you’re back into your original bug… at the same file, perhaps even at the same mouse location.

That’s context switching. You’ve moved from Thing 1 to Thing 2. When finished with Thing 2, you moved back to Thing 1… right where you left off. You’ve reconstituted your original context.

This is the second problem mylyn solves: it helps you move from task to task and back again.

I recently wrote about how I do this context switching with my favorite Mylyn toolbar item, and I invite you to read that.

Part 3: Context Sharing

At work in particular, I often work on something and then sometime down the road, I need to work on something similar. If it hasn’t been too long, I’m likely to remember that thing I worked on. I’ll search Jira and find the issue number.  Wouldn’t it be nice if I could take that “context” (remember… for us, Context means basically  “a collection of files”) and copy it to my new Jira issue? With Mylyn, you can do that:

From the “task” editor for the original task, I go to the Context tab and click “Copy Context to…”. It pops up a task finder, I select or search for the new task, hit a button, and bam, done.

Now, I deactivate that old task, activate the new one, and this is what it looks like:

That’s right… just like the “source” task, except in a new task. My original task remains untouched, and anything I add or remove from this new one is unique to just this task.

This is the third problem mylyn solves: It literally takes seconds to transfer the “mindset” of a previous task to a new task.

Summary

As developers, we are expected to be more and more productive. By default, constant stop/start – constant context switching – is anathema to productivity. Mylyn helps mitigate the pains associated with this kind of chaotic working style, and that’s why it has become one of my most valued and loved tools.