Mylar’s task-focused user interface is a new technology that represents a fundamental shift in the way IDEs work. Today’s applications and frameworks are composed of millions of lines of code, and what state-of-the-art IDEs have done is made all of that code instantly accessible. But when used on large systems, the IDE view and search facilities often contain thousands of elements. The result of this information overload is that developers often spend more time repetitively scrolling, searching, and navigating code than they do programming. The key intuition behind Mylar is that for any task that we do, any bug that we fix or feature we add, we only care about a subset of the system. Mylar makes this subset explicit by transforming our programming activity into a task context model. The result is that structure views show only the relevant information, changes are grouped by task, multi-tasking only requires a single click, and expertise becomes easy to share and recall.
In 2003, I was working on integrating new modularity technologies with IDEs. Model-driven and aspect-oriented programming tools showed promise in removing significant amounts of the accidental complexity that creeps into our systems. But even with improved modularity, it became clear that the essential complexity of systems would continue growing, while our ability to deal with that complexity would not. I had noticed interesting research on the FEAT and Hipikat projects, and realized that Gail Murphy, a professor at the University of British Columbia, had a deep appreciation for this problem and a uniquely practical and empirical approach to finding solutions. She convinced me that the best way to to tackle the problem was by doing a PhD.
I have loved programming since I was ten years old, when I learned English from a Sinclair ZX1000 BASIC manual. After completing my undergrad and joining the AspectJ team at Xerox PARC I got infected with a passion for building tools that make people more productive. What would sometimes slow me down is RSI that resulted from very long workdays. The start of my thesis gave me a chance to reflect on what the underlying problem was: I was constantly clicking the mouse and keyboard to find and re-find the information I needed to get work done. What I hadn’t noticed before is that I was always browsing and searching for the same elements because the tools I was using buried them within deep hierarchies instead of grouping them in a more reasonable way. Gail and I brainstormed weekly on how the structure relevant to developers’ tasks could be identified and presented. She instilled in me the need to validate any whacky ideas that we came up with via user studies, and in August of 2004 we installed Mylar 0.1 on six IBM developers’ desktops. We measured their usage patterns before and after they had Mylar, and found that when the IDE views were focused on task, they would spend more time programming and less time clicking around looking for the information they needed to program.
We presented Mylar 0.2 at the EclipseCon 2005 conference in order to find more study subjects. This caught the eye of Bjorn-Freeman Benson, who got the idea instantly, and suggested that we propose Mylar as an eclipse.org project. On July 4th, 2005 we released Mylar 0.3 to the first hundred developers who were willing to participate in our user study. Four months later we had collected enough data to validate with statistical significance that Mylar makes programmers more productive. Thanks to the constant releases and the fact that all work done on Mylar was done with Mylar, by that time we had produced a reasonably well-integrated tool that we were happy to share with others. Mylar 0.4 was our first public release on eclipse.org, and happened on November 4th, 2005.
At that point, an amazing thing happened, and has continued happening since. Developers kept getting addicted to Mylar. Like us, they couldn’t imagine working without it, and became as passionate about having it support their workday as we were. A steady stream of bug reports started rolling in, and defined how programmers needed Mylar to work in order to support their development process. Many bug reports were accompanied by patches that helped Mylar evolve to meet these ever increasing needs. Since then we have resolved 1826 bug reports, over 200 of which were resolved by community contributions.
The result is Mylar 1.0, which integrates task context seamlessly across the Eclipse IDE, and brings developers’ tasks into Eclipse from repositories that include Bugzilla, JIRA, Trac. More importantly, Mylar 1.0 provides frameworks to integrate task context with other kinds of artifacts and task repositories, which enables integrators to provide Mylar's benefits to a rapidly growing number of developers.
Gail Murphy and the Department of Computer Science at the University of British Columbia created the academic environment that made it possible to bring Mylar from blue sky brainstorming, to a tool used daily by thousands of developers, in less than 3 years. The IBM Centre for Advanced Studies and NSERC funding of my PhD made it possible for me to focus all of my energy on the implementation and validation of Mylar.
Robert Elves, whom Gail and I discovered after seeing his research on using Eclipse navigation to rank editors by relevance, is the main reason that the Tasks framework works as well as it does today. His relentless drive and tireless effort have single-handedly supported the requests and needs of hundreds of Mylar users. Steffen Pingel and Eugene Kuleshov have provided countless valuable contributions to Mylar, and thanks to the eclipse.org process of meritocracy, have become committers on the project without ever meeting face-to-face with the other members of the team. The following individuals have also made substantial contributions leading up to Mylar 1.0 (in order of bugs resolved): Shawn Minto, Ken Sueda, Jeff Pound, Wesley Coelho, Willian Mitsuda, Brock Janiczak, Lean Findlater, Nathan Hapke, Raphael Ackermann, Meghan Allen, and Gunnar Wagenknecht.
Mylar would not have been possible without the remarkable extensibility of the Eclipse Platform. We extend a huge thank you to the teams that created the Eclipse SDK, and to their self-hosted and open philosophy of building tools. Their work has resulted in the most extensible and comprehensive tool framework, a vibrant user community and a platform for innovation.
Finally, the seeds of these ideas came from
Gregor Kiczales constantly repeating
“less is more” over my shoulder when I was getting buried in complexity, and
“first things first” when I was mismanaging my tasks. It brings me great
satisfaction that Mylar provides tool support that automates his advice.
Happy coding,
Mik Kersten, project lead
2006-12-11