In Search Of Agile Architecture

As you know, the Agile movement was formulated as a response to the perceived need for an approach to software development that could easily accommodate change. It was presented as an improvement to the so-called waterfall model, which was predicated on an extensive design cycle that defined fairly unchanging requirements and designs. Because of this, waterfall models tended to deliver software that was out of sync with the user's needs due to the evolution of the latter during the development cycle.

At its inception, the Agile movement was not about techniques, but about principles. However, extreme programming (XP) was one of the most established set of Agile practices at the time and so it provided the body of practices with which Agile came into incarnation. For many years, XP practices and Agile approaches shared a great deal of overlap. Later they would become more differentiated, but early on they were essentially the same.

XP, as the P implies, is focused on low-level work. It consists of 12 practices, seven of which are exclusively about coding-related work: pair programming, test-driven development (TDD), refactoring, small releases, coding standards, collective code ownership, and system metaphor. The remaining five practices barely hover above this level: planning game (weekly iteration planning), whole team, continuous integration (building the code trunk repeatedly), simple design, and sustainable pace. This makes XP a great solution if only your coding or implementation pipeline need remediation. But experience tells me that sites with faulty downstream processes often suffer from problems further up the line than what can be addressed by practices such as TDD and CI.

Read the rest of this article on Dr. Dobb's.