Mylar...Why should you get it?

The Mylar plug-in allows you to associate a context of work with a particular eclipse task. What does this mean? Well, after 'activating' a task for the first time, you are provided with a clean slate view in terms of classes, configuration files, etc... in your project. As you begin to navigate the code-base while working the task, the classes and methods you interact with become part of the task's context. The benefit of this is that it reduces 'conceptual overload', therefore, making you more productive. The best way to understand this is to see it in action. On top of that, this 'external navigational memory' is constantly changing based on your code interactions. The context adapts to your current code usage pattern as you are working the task.

The task context can even be shared between developers on the team and associated with various issue tracking solutions (Bugzilla, Trac, Jira). I have yet to try this since my current project does not use the supported issue tracking implementations, but it seems very cool.

I have to admit it, I have been putting off installing this plug-in for some time and I regret that. I think it is one of those things that you need to experience to fully appreciate. If you do any development with Eclipse, get Mylar now!

I just wanted to let folks now that I will be blogging all future XNA-related content to my new blog XNA Zen Garden. Pop on over and you'll find it's inaugural post on C# partial classes.


I moved my previous XNA-related posts to the new blog as well.

But it works...Isn't that good enough?

Well, it depends. However, more often than not the answer is no, it is not good enough.

Imagine your working on implementing a 'fix' for a 'show stopper' issue under an 'aggressive' dead line. I bet this does not sound too far fetched?

I would bet that you are not particularly comfortable cranking out a quick work around solution, yet I am sure that you find the quick fix so damn tempting.

Why is that? For one thing, the client probably wants this issue fixed yesterday! Deep down, they may not care how it is done. The bottom line is the sooner the better. Of course, doing it right is implicitly assumed but, this is usually sacrificed in the spirit of the Now. In fact, we are often rewarded for getting things out fast. Perhaps there are financial incentives for getting things done on schedule? In my opinion any sort of incentive tied to a schedule is a smell indicating that the schedule is just not right.

My colleague Dmitri Dolguikh recently pointed me to a great article concerning how costly quick fixes can be. I found the last two paragraphs particularly interesting:

It comes down to a matter of professional ethics. Software developers are often disparaged for being sloppy, slow, and unreliable. Whole IT departments and product develoment teams carry the weight of appearing incompetent and moribund. Why? Because they succumbed to the seductive idea that quick and dirty solutions are faster in the short term.

True professionals don't work that way. True professionals keep their code clean at all times. True professionals write unit tests that cover close to 100% of their code. True professionals know their code works, and know it can be maintained. True professionals are quick and clean.

I whole-heartedly agree with this, however, the reality is that being a true professional is not easy and, depending on the environment, may not be realistic 100% of the time. There are too many opportunities lying in wait to distract us from this ideal. In my view, a true professional is analogous to the notion of a responsible developer. To quote a recent post by Kent Beck on the XP mailing list:

I try to do an excellent technical job but I also work to make sure that what I am doing fits into the larger business...If the technical concerns and the business concerns appear to conflict, I work to find a mutually beneficial solution but finally I follow business imperatives over technical ones.

We work within the constraints of our current environment. Although the true professional definition as put forth by Bob should be an ideal that we continuously strive for, it may not always be achievable. In those cases, does that make you less responsible or professional? I don't think so.

We cannot solve all the problems of an organization, but we can do our best to help steer them in the right direction. Sometimes this requires a compromise.