Why is software so difficult to change? When you establish your initial vision for the software’s design and architecture, you imagine a system that is easy to modify, extend, and maintain. Unfortunately, as time passes, changes trickle in that exercise your design in unexpected ways. Unlike what you had anticipated, each change begins to resemble nothing more than another hack, until finally the system becomes a tangled web of code that few developers care to venture through. Eventually, modifications to the software intended to improve the system have the opposite affect of breaking other parts of the system. The software is beginning to rot.

The most common cause of rotting software is tightly coupled code with a heavy dependency graph. This session explores the most common symptoms of rotting design, examine their root cause, and present techniques and patterns that have been used on a number of real world projects to help manage dependencies across classes, packages, and the binary units of deployment.

Traditionally, we attempt to make the right architectural decisions early due to the significant anticipated cost affiliated with making incorrect decisions. But this contradicts agile practices which have taught us to embrace change. So how do agile and architecture come together? Conceptually, the goal of agile architecture must be to eliminate the architectural significance of change by crafting software that can easily adapt to change. In practice, developing agile architecture is much more difficult.

Software architecture is organic. The architectural goals you set to achieve early in the development effort differ from those you'll need to satisfy later. Change occurring throughout the software development lifecycle impacts architecture. The ability to accommodate shifts in architecture is directly related to the dependencies between software modules. In this session, we examine patterns and principles that lead to agile architecture. Extensive discussion is devoted to modularizing units of deployment, and how code can be created and organized to create more flexible, reusable, maintainable, extensible, and testable software components. Topics of discussion range from coupling between classes to the dependency structure between your modules of deployment. Examples gleaned from real world J2EE development effort will be used in a pragmatic case study that examines the evolution of a system from its initial deployment through a number of refactorings that positively influenced the architectural resiliency of the final product.allow you to apply many of these concepts immediately.

Agile processes such as XP and RUP advocate continuous integration, where shorter iterations produce an incremental and functional growth of the system. The fundamental component of any Continuous Integration strategy is an automated and repeatable build. In addition to ensuring your application is always in a functional state, a robust build strategy enables a number of other important lifecycle activities.

This session explores the important characteristics of Continuous Integration, including the development of an automated and repeatable build, and numerous other utilities that enrich the build process. We will also explore the important long term of Continuous Integration by examining it's use on a real world project. Multiple examples using CruiseControl, Ant, and other third party utilities will be shown, and tales from a project experienced in CI will be shared.

Design Patterns are proven and powerful techniques that can help improve the resiliency, maintainability, and extensibility of your applications. However, overusing or misapplying patterns is a common mistake often times resulting in applications that are over-architected, and resemble a tangled web of classes. How can patterns be applied to achieve the goal of better software?

This session offers a gentle introduction to design patterns by examining a small, yet very usable framework designed using 7 common GOF patterns. We?ll examine the framework, and explore how each pattern is used as well as how each pattern emerged based on real, instead of perceived need. Less flexible alternatives to the chosen patterns will also be discussed. To conclude, we?ll examine how the patterns are applied in conjunction with each other, forming more complex compound patterns. Each pattern will be presented with accompanying source code, and all examples are gleaned from real world scenarios.