Microtest Test-Driven Development is a strategy for *change*. To understand the case, we need to answer two questions: 1) Why have a strategy for change? 2) How does TDD provide one? Let's take up the first question today.

(Before we begin, I remind you of the relative unimportance of geekery to me just now. This is just respite.

Please work for change and support the others who are doing so.

Black lives matter.

Stay safe, stay strong, stay angry, stay kind.)

Why is having a change strategy so urgent?

The TL;DR is dead simple:

Because continuous ongoing change is at the base of all software development, both before and after our software is in the field.

When I read old-school software ideas, or for that matter what is being taught in our colleges for the most part today, I'm struck over and over again by the "timeless" aspect of the material. It is concerned almost entirely with the static and atemporal aspects of software.

In these approaches, applications spring Athena-like from the heads of our pantheon-worthy programmers. The designs emerge in an instant and once emerged they are final. The process looks like 1) Nothing. 2) Everything. 3) Move on.