Greg Young discusses eight lines of very common code finding in them massive numbers of dependencies and difficulties, looking for ways to get rid of them.
Sandro Mancuso runs a hands-on demo adding tests to a Java legacy code then refactoring it.
Simon Thompson introduces Wrangler, a refactoring tool written in Erlang for Erlang code and embeddable in common IDEs, such as Emacs and Eclipse.
Nat Pryce considers that we cannot write the perfect code because it is never fully prepared for the coming change, so he suggests embracing impermanence & continual imperfection.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Jason Gorman presents how developers can learn TDD to the point of transforming the knowledge acquired into habits by exercising a number of practices over a period of 4-6 months followed by evaluation done by fellow co-workers.
Ralph Johnson discusses principles, practices and tools relating to software development starting not from scratch but from already existing code which needs refactoring, maintenance, and sometimes architectural change.
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.