Soapbox Rants and Raves

Early in my software development career, I had the good fortune to be mentored by someone who was an Emacs guy.   After much complaining about the crazy, obscure key combinations, Emacs became my weapon of choice and I actually became pretty good at hacking LISP! I am still an Emacs guy, but only those crazy key bindings live with me today. We used to joke that Emacs was not an editor, but an operating system! I would start up Emacs in the morning; it was the only tool I needed all day. I could read my email, read news, compile code, debug, and even play games (which I never did, but thought it was cool!).

So, why is this history lesson important? It is all about focus and productivity. By allowing the developer to accomplish multiple activities within a single tool, helps them stay focused on the task which they are trying to complete. By minimizing the need to switch tools, the developer can easily toggle between the different activities, without interruption. Think about all of the different tasks that one does developing software; the most basic ones being managing problem tickets or programming assignments, interacting with the configuration management system,  writing code, and executing unit tests.  I have worked in environments where every tool operated in its own isolated world, with little or no integration to other tools. Each time I changed tasks, it was like a huge context switch: 1.) start the problem ticket tool 2.) Locate the ticket information 3.) Put the ticket in the correct state 4.) Check out the code 5.)  Edit the code 6.) Test the code  7.) Repeat selective steps.  Quite a process; it could actually involve using four different tools, just to change the code! The problem is even worse, when you are working on multiple tickets?  It can be a little more than challenging to keep the changes associated with the proper ticket.

Eclipse and other Integrated Development Environments (IDE) have evolved into the world that was once dominated by Emacs. These IDEs have literally hundreds of custom plug-ins that allow the developer to stay focused on the task at hand.  The IDE provides more than simple access to the supporting tool (via a plug-in), well designed plug-ins are able to integrate information into the current context of the developer’s activity. Plug-ins seem to take one of two integration approaches, task management or task support.  I consider task management a major activity such as ticket management or debugging. The plug-in developer would provide a big picture (multi panel) view of that task, a perspective in Eclipse terminology. From this perspective, the developer can focus on all of the activities that are relevant to that task. Task support is the alternate integration approach; this allows the developer to customize the task management perspective, by adding additional, supporting  panels; a view is Eclipse terminology. These panels show specific, subset information about different, potentially related task, such as coding problems, J2EE server status, or a selected class hierarchy.

It is this customization and integration with the task management perspective that highlights the true power of an IDE. Simple integrations include code quality plug-ins that highlight non-conforming or poorly structured code as the developer is type. One of my favorites is integrated code coverage tools; untested conditionals and statements are automatically highlighted in the editor after running a unit test.  This is the big win, focus plus productivity. Developers can now concentrate on their primary task and the output from supporting tools is seamlessly weaved into the process by the IDE. No need to switch windows or applications, everything they need is right there in front of them, exactly when they need it.

Just like many of my posts, they started off in one direction and end up in a completely different one! I really wanted to write about an interesting plug-in called Mylyn, which is a task focused interface for Eclipse.  The integration aspect of Mylyn with Eclipse is very  intriguing. Hopefully, my next post will explore how Mylyn could be used to make developers more focused and provide management with a more realistic perspective of the project’s progress.