As developers, we're familiar with the endless pains that result from maintaining overly complex systems. Some complexity is accidental, so we continually strive to remove its overhead from our application. The latest crop of frameworks and dynamic languages has demonstrated just how far simple implementations can go. However, many applications have an essential complexity that cannot be further reduced without sacrificing end-user functionality or integration.

When trying to figure out how we make our workdays easier and our programming hours more effective, the key questions we are faced with are:

1. How can we reduce accidental complexity when building an application?
2. How can we manage the inherent complexity that's there?

The key property of an effective programming language is that it makes it easy for us to build systems in a modular way. Good modularity means less accidental complexity, easier maintenance, and more flexibility in the face of changing requirements.

While modularity mechanisms can introduce some up-front costs and may slow prototyping, for many applications the static typing and object-oriented modularity have made Java a great choice for building large enterprise applications.

One of the key properties of the frameworks we choose is that their programming model fits our application's needs. We also rely on frameworks to insulate us from the complexity of the various technologies that we build on to easily get data from its source into the presentation layer of the UI. For many, the Spring Framework has provided a golden combination of simplicity, modularity, and integration with other key libraries and frameworks that make up the enterprise application stack.

In other words, it looks like we're doing pretty well in terms of minimizing accidental complexity of enterprise applications. So why does it still feel so hard for us to get started fixing a simple bug in a large enterprise application? A critical problem is that current tool support offerings are not sufficient in helping us work with the essential complexity of large applications. Consider a medium-size application that consists of a few hundred thousand lines of code and builds on up to a few million lines of library code. No matter how simple the bug we are trying to fix is, the IDE tools that we use today surface all of that complexity to us. While the IDEs have become amazingly efficient at building and presenting the entire structure of large systems, they take the compiler's and not the programmer's point of view. As a result, a simple search of the source will often lead to hundreds of results scattered through the entire application and its libraries. This compiler-centric approach causes severe information overload in the structure views we rely on, which commonly show hundreds of files or elements and require constant navigation, scrolling, and searching. The result of this mismatch is that we waste a lot of time repeatedly navigating around the application instead of getting work done.

However, the face of the IDE is changing. Just as open source and community involvement have enabled the Spring Framework to evolve so rapidly, the openness and community of the Eclipse ecosystem have fostered a tool platform for innovation.2 This has enabled the Eclipse Mylyn project to make a fundamental evolution of the IDE UI that makes it much easier to work on large systems. Mylyn achieves this by monitoring your programming activity in order to show you only the information relevant to the task at hand. It also provides a rich UI and integration for issue trackers and version control systems, making it much easier to multi-task when jumping between the large number of defect fixes of the enhancements involved with a large application. However, like the Eclipse SDK, Mylyn tooling is targeted at Java SE and Eclipse plug-in developers, relying on extensions to properly support Java EE development. Since Mylyn is very new, such extensions have not been available to date.

Things are about to change. An open source collaboration between the Mylyn and Spring IDE projects has already started providing a preview of how effective Mylyn's Task-Focused UI can be at easing the complexity of Java EE development. Consider Figure 1, where in the background you see the typical Project Explorer, overloaded with irrelevant library classes, and in the foreground a Project Explorer and bean editor focused to show only the beans, Java source, and Spring libraries that are relevant to the task at hand. This task context can be easily stored, set aside, shared with team members, and recalled when needed. Once you return to the task, you instantly see all of the Spring beans and Java code you were previously working on.

This is only the beginning. The recently announced partnership between Interface21, the company behind the Spring Framework, and Tasktop Technologies, the company leading the Mylyn project, mean that the Task-Focused UI will soon be supporting much more of an enterprise application's life cycle. In other words, just as Mylyn has already simplified the development of large Java SE and plug-in applications, over the course of the next year we are going to see the same simplification working across the various resources, frameworks, and tools involved in building Spring-based Java EE applications.

The final thought to keep in mind is just how far this combination of Spring, Eclipse and Mylyn can go. The static nature of Java and the quality of the OSGi component model have made it possible for Eclipse to provide a remarkable set of productivity features such as consistent refactoring across Java and plug-in resources and easy launching and debugging of plug-in based desktop applications. The Spring Framework is building on the very same Java and OSGi technologies and the Spring IDE has started reusing the same Eclipse frameworks. Eclipse plug-in developers are already spoiled with a dramatically easier way of building applications and are incapable of going back to a day in which the IDE support did not provide them with this high level of automation at both the language and component level. While the much more heterogeneous nature of JEE applications makes this kind of automation more challenging, the latest developments in the Eclipse WTP and Mylyn frameworks provide key enablers. It is high time that Java EE developers start feeling spoiled by their tool support as well.

References
1.  http://en.wikipedia.org/wiki/The_Mythical_Man-Month
2.  http://tasktop.com/blog/?p=5