Joshua Kerievsky discusses the need to reduce “red” periods of time while developing software. One is in the red when he spends too much time designing, or having compilation errors or the tests do not pass. Kerievsky demonstrates a method (Parallel Change) of reducing the red while refactoring code, and discusses another approach called Narrowed Change, and answers refactoring related questions.
Dan North discusses an example of rearchitecting an application without rewriting it from scratch, and explains general strategies for a holistic rearchitecture such as changing the team culture, removing obsolete technologies, allowing mistakes to be made (and learned from), transitional architectures, introducing bounded contexts, refactoring and emergent simplicity, and rotating through roles.
Many people assume that agile methods mean an absence of design. Design still happens in agile projects, but it shifts from an up-front phase to a continual evolution. Design decisions should be left to the last responsible moment, but some design decisions do need to be made at the start of a project. Martin Fowler explores this topic through a panel discussion of design in an agile context.
Bob Martin of Object Mentor presents the first of his five principles of agile design. Beginning with an explanation of the real purpose of object-oriented design - the management of dependencies - Bob walks through a code example to illustrate how dependencies can be managed with abstractions, and that good designs are those in which high-level abstractions do not depend on low-level details.