When I first started programming, it was with a small company. Life was simple. I understood all the requirements, and knew all the aspects of the application and how to pull everything together. If I was working with a team of programmers, the projects were small enough that the team knew each other's code thoroughly. Mi code es su code. Software engineering was easy to follow; code and design walkthroughs involved everyone, and, given time, any person could pretty much handle the whole project on his or her own.

I moved on in my career and, in the last decade, as technology started to grow at a phenomenal rate, the process of "pulling it all together" became far more complex and had a lot more nuances than a single person or team could handle. Distributed computing, by its very definition, requires distributed components to work together as an integrated application. This introduces the need to independently test and deploy the components, to provide an appropriate level of abstraction, and then to test the application as a whole.

The J2EE platform's purpose in life is to facilitate the development and integration of distributed components. Sun provides the APIs and the framework. However, the actual tools for testing and deploying an application are provided by IDE tools vendors. Fortunately, J2EE IDEs have come a long way in offering features that support the design and testing as well as deployment of J2EE-based applications.

As distributed programming platforms have evolved over the last decade, so too have the design methodologies. About four years ago, you got the J2EE APIs (which were not yet "J2EE") from Sun, the J2EE implementation and container for distributed components from your app server vendor of choice, and the development environment from your favorite IDE. To coordinate between development, testing, and deployment, you had to manually make these different environments work together.

Over the past few years, several things have happened to make the development of J2EE applications both easier and harder. It's harder because the complexity of APIs has grown to an extent that the developers can concentrate on only a part of the big picture. The architect who designs the solution has the big picture in mind, but had to leave the details of subsystem design, testing, and deployment to the individual subsystem designers. Development of J2EE-based applications has become easier because the tools have become more integrated and alternative, less heavyweight methodologies have become very popular.

eXtreme programming has gained a lot of popularity in the J2EE universe overall because it offers a practical and efficient way to manage large or small projects without getting bogged down in an overly complex design and an unmaintainable development cycle. And XP has become very popular in the Java environment because it addresses the needs of distributed J2EE application development in a palatable way. IDE and app server vendors have added support for J2EE tools using XP as well as support that enables teams to develop software based on XP principles. The leading app server and IDE vendors typically include support for tools, such as Ant for building and deploying software and JUnit for testing, and editing support for refactoring. The XP principles apply well to a distributed development environment by reinforcing simple design and continuous integration, refactoring coding standards, and code sharing through pair programming. While these principles apply well to all projects, the supporting Java tools make the application of these principles pragmatic.

It would be nice to have a tool that enforces pair programming. Maybe that's coming soon. Speaking of eXtreme J2EE, there are a couple of good books I'd like to recommend on this subject: Java Tools for eXtreme Programming by Richard High-tower and Nicholas Lesiecki (Wiley), and Java Development with Ant by Erik Hatcher and Steve Loughran (Manning Publications).