Advice about software design focuses on the principles designers should adhere to and the structures that should be created. This leaves designers prone to creating the right design at the wrong time. "Why, When & How" fills this gap, giving designers an understanding of the overall goals of software design, when various techniques become relevant, and how to move smoothly from yesterday's design to today's.
A goal of software design is to enable changes to a program. We may optimize the speed with which the next feature appears (latency), the number of changes per unit time (throughput), or the predictability of features (variance).
Software design is also an aesthetic experience for the designer. Optimizing for minimizing discomfort or maximizing satisfaction may conflict the the economic goals of the system.
The presumed high cost of change has led to bias for early design. However, speculative design comes with substantial costs. What are the tradeoffs that go into the decision that today is the day to change a design? How can designers actively use waiting as a design activity?
How can large changes to software design be made quickly, cheaply, and predictably? My bias is towards making large changes in small, safe steps. How is this practically done on large, production systems?
Kent Beck is Chief Scientist at Iterate. He is best known for software patterns, test-driven development, Extreme Programming, and JUnit.