More on Mylar: Tasks, Picking, Agile ALM

I was talking with someone today about Eclipse Mylar and they asked me if it was a threat to commercial offerings. That’s sort of the standard Eclipse questions, right?

I should disclaim that I haven’t actually used Mylar, I’ve just seen demos, read about it, and talked with the team lead, Mik Kersten, and Ian Skerrett. Also, of course, Eclipse is a client. With that out of the way…

What is Mylar?

At first, Mylar may seem boring to most developers: task lists and context filtering don’t have the gams that AJAX and distributed transactions do. But, once you realize it’s potential for making your day-to-day life easier and the calming effect that effective task management can give you, you might like it.

First, what’s Mylar? Here’s a quick take (forgive the brevity):

• An enhanced task manager that can integrate with 3rd party services (bug trackers, etc.)
• Functionality to focus your UI on only items related to a selected task, creating a filtered context. This is like the Working Set, except done automatically and much more detailed.
• The ability to capture a those filtered contexts and store them for later use.

Mik provides a more in-depth explanation is his two part (1 and 2) article on developerWorks.

So What?

As is often the question, why does this matter? A developer spends days tweaking their IDE setup to be just right and match their workflow. Once established, there needs to be good reasons to change it.

Tasks, Bugs, and Issues

The first interesting part is the enhanced task management. Eclipse already has a task window, which is great for listing warnings, errors, and @TODO’s. Mylar’s task manager is a much more full-fledged one that can integrate with third party systems. There’s an API to integrate with bug and issue trackers, and there’s also a “web connector” to hook up to less API friendly applications.

Once you’re connected to the 3rd party service, you can query and edit the bugs or issues in it (depending on the support). What’s nice here is that you can stay in Eclipse to lookup and edit bugs and issues. “Issues” of course can be requirements, stories, or tasks (that’s where the ALM angle comes in later on).

Less Context Switching

I’m big into reducing context switches, so to me this seems like a big win. Once I switch out of Eclipse to look at a web or other UI to check on a bug, I’ll probably go get a cup of coffee or read blogs for 10-30 minutes.

Micro-manage Yourself

More importantly, closer task integration allows individual developers and teams to manage their own tasks rather than have a manager breathing down their neck all the time to update The Spreadsheet or Project file. That’s one of the subtle, perhaps counter-intutive efficiencies of Agile: managers should do less managing…as long as the developers, QA, and others can do it themselves.

All you GTD nuts out there should like this idea.

Better Working Sets

More important than just CRUD’ing over tasks, Mylar actually uses the tasks you’re working on to set the filtered context in Eclipse. Think naked desktop for your IDE.

Eclipse users probably know about Working Sets: you can manually create filtered views of your code base. So, if you have a long-lived, successful project, you probably have 1,000’s of classes and other files. If you’re just working on a sub-set, it can be nice to focus in on just the relevant items.

Instead of having to manually create these filtered contexts, Mylar analyzes which files you’re accessing, infers what related files are, and also pulls in related items depending on which task you’re working on. Sure, it sounds like dev-voodoo. On the other hand, I can see how Mylar could make pretty good inferences — even “dumb,” but helpful ones — about relevant context based which class is using which and which execution paths are followed. I didn’t go over the algorithms it uses too much. Perhaps some early users can tell me how it works out for them.

“Pickling”

The thing that I really like about these Mylar created contexts though is the ability to persist them. That is, once a context is created, you can tell Mylar to save it, move on to another context, and then bring that old context back up. The idea here is to limit the effects of context switches:

• You’re working on a feature for the upcoming build of the product.
• A QA person comes and tells you that your latest build causes the servers to instantly blow up. You need to fix your build.
• So, you save your current context with Mylar, and go work on The Bug.
• After “fixing” the bug (user error! again! is it so hard to edit that XML config file?!), you use Mylar to re-load your context.

Now, of course, you’re still going to go get a cup of coffee before switching back from the bug to your original context. But, at least set up time isn’t going to be as long.

A few other products have, or will have, functionality like this and the idea comes up frequently now-a-days. The first time I heard of it was from the Austin company, Smart Bear Software (founded by an old high school friend), with their CodePickle product. As I recall, Visual Studio also does this, and as seen at JavaOne this year, so does Rational’s mysterious Project “Jazz” (“we’re all expecting big things, Fink.”).

Part of the potential for this “context pickling” is making time-shifted collaboration easier. That is:

• One developer could create a context when they found a bug and store it in the issue tracker
• Another developer can pick up that issue, downloading the picked context, and setting their IDE up just as the first developer had.
• Or, months later when either of them gets the task again and has no idea what it’s about, they can get the context, and by seeing only the relevant code and files (hopefully) remember what the task was all about.

You could imagine that this would be useful for code reviews as well…which is one of the core things the folks at SmartBear do.

Contexts + Tasks = Code Accounting…ALM?

With the pickled contexts and tasks together, you can start to associate moments in workflow and states in code with a requirement or bug. The idea here is that you could take any given requirement and ask the question “show me the relevant code and files.” Once you have that, with some degree of sloppiness, you could run the relevant tests and then say “this requirement is ‘done’ and tested.”

Now, I say some degree of sloppiness because that’s not going to work 100% of the time. More importantly, I think this use is theoretical at a large, automated scale on my part.

But, adding in that the implementation of that theory is what made me say that Mylar has the potential for an Agile ALM platform, as Ian noticed.

The Zero-Sum Question

Getting back to the standard Eclipse question — is it a threat to commercial vendors — the answer is that in the area of project management and ALM, not at the moment. But, the task manager tied up with the context pickling has the potential for an interesting, maybe new take on project management or even “Agile ALM.”

That said, I’m impressed with Mylar. It manages to have that moment of delight on contact that makes you want to try it out. If only I had more excuses to dust of Eclipse now-a-days and write some code ;>

I suspect that rather than compete or threaten others it’ll be used to enhance or inspire others IDEs.

For example, I’d think Rally would be incredibly interested in integrating Mylar with their Agile project management suite. They have an Eclipse plugin, but from what I hear, it’s no where near as swanky as Mylar could be. Other Agile project management vendors, of course, would be interested too.

Time will tell though if the developers like Mylar and start using it. I’ll be keeping and eye on it to see what happens.

Disclaimer: as mentioned above, Eclipse is a client, as is IBM.

Tags: eclipse, ibm, jazz, mylar, projectmanagement, rational