Introducing SHOC Modular Design Principles...

S - modules should be Swappable

We can swap implementations of SalesRate in LeadTimeReorderLevel, so we can - for example - stub it for a unit test or vary how the sales rate is calculated, with no impact on the client code H - modules should Hide their internal workings

The details of how the area of this rectangular room is calculated are hidden from clients. It could be an L-shaped room, or a circular room, and the client code wouldn't need to change.

We make a point of not trying to sell TDD when we teach it (because if you don't wanna learn, you ain't gonna learn). But, if you're wondering, here are the main reasons *we* do TDD

1. It forces us to really think about *what* we want the code to do, before we think about *how* 2. It gives us rapid feedback that our *how* is working

Here's a little exercise for a team to try.

Break into pairs. Each pair thinks of a real-world problem that might be solved with some simple software. Not a *solution* - a problem.

e.g., It's hard to find a parking space

Regroup, read out the problem statements and vote. 1/n For the problem the team agrees on, imagine a feature - a proverbial "button" - that when you click it, the problem is solved.

e.g., You are directed to the nearest available parking space.

This is your "headline" feature - the feature for which the software exists.
2/n