"Your tests failed. Again. And they didn't just fail, they failed you. There was no bug. There was no regression. You changed something trivial - an implementation detail - and your app still works but your tests are broken. They don't have your back. What purpose do they serve?
In this talk we'll evaluate the unit tests from an open source codebase. We will cover the roles a test plays in the lifecycle of a project, and explore guidelines that let us assess their worth, and determine which tests should live, which must die, and which are missing"
Does the architecture of your application tell you the intent of the application, or does it just tell you what frameworks you’ve used. A good architecture screams about the intent of the application and hides the frameworks. In this talk, Uncle Bob talks about the lost years of architecture, about how the web is just a detail, and about the best kind of architecture to use for your applications.
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.