TDD: For Those Who Don't Know How to Design Software - The Code Whisperer

[jbrains]

@jds

If we accept the notion of program as constructive proof (albeit one with effects–which are deeply confounding compared to the enterprise of mathematics, the theorems of which don’t generate heat when applied, for instance), then refactoring becomes something like a proof that two programs are homotopic (i.e. can be continuously deformed from one into the other).

My topology is weak, but I remember enough to understand this. Indeed, one key advantage to homotopy is that if we have one thing, then we can reliably get the other thing. Refactoring, to me, means more than merely “I can improve this design safely”, but rather “Since I know how to improve designs safely, I don’t have to try to design systems as well as I possibly can the right time.” This provides immense freedom to alternate one’s energy between making it work and making it less stressful to change.

@jds

Analogously, if we think of design as the meta-level work of writing some proof in the first place, then one could reasonably contend that the least interesting results will be the ones we generate without effort; the conjectures are where the action is! From this perspective, there simply is no lofty place from which we can stand, knowing precisely what lemmas (components, perhaps) to write or what existing theorems (say, libraries or services) to rely on.

I never worked as a mathematician, but I was an enthusiastic student. Once we got past the basic forms of argument and the elementary proofs with “neat tricks” (sqrt 2 is irrational, there is no largest prime, the equivalence of DFAs and NFAs), finding a new(-to-me) proof was rarely an exercise in thinking hard then writing a sequence of steps, but rather of messing around until I found the key idea that made both ends of the argument fit together, then simplifying some steps to arrive at a proof that was both correct and easier to follow. Given this, sneaking up on a software design that satisfies us seems self-evidently sensible as an approach.

@jds

Even supposing TDD was a purely superstitious ritual, on par with an athlete refusing to change their “lucky socks” during game season, we cannot conclude that the practice isn’t at least valuable to the practitioner.

Moreover, as we’ve found in more-recent sports psychology circles, these rituals have less to do with false causation and more to do with creating the mental conditions in which the body spontaneously performs the right actions for the sport. As I like to say—and I don’t remember whether I stole it from somewhere, but I like it----superstition = routine + fear. We encourage the routine without the fear. Practising TDD helps me create the mental conditions for both focusing on wrestling with how That Thing Over There is supposed to work and for insight to visit, so that I realize why this code is really a tree and so Composite will make it much easier to work with. No fear involved.

Thank you.