I’m bettin’ u already got some code. If yer a geek in a substantial code base in an org w/more than a half-dozen other geeks, i’m bettin’ u already got a lot of code.
In your team’s head, if not somewhere on an out-of-date piece of paper, there is a picture of "our code". I want to draw a box somewhere where there’s room in that picture, and I want to label it "rigorous".
Let’s call it the rigorous playpen. And what we want to put in that area of our codebase, is only file-pairs about which we can make this statement:
This code (T) tests that code (P). If u can break our app in that code w/o this code telling u u broke it, call us, any time day or night, and we will come running.
I have some questions & comments about this idea. Do you get it? That is, does it seem pretty clear what we’re asking to go in the rigorous playpen?
Under what circumstances might you move one of your file-pairs in to that category? It would seem to require a substantial amount of judgment & experience to designate some file-pair as being in the rigorous playpen.
If we had a rigorous playpen with some code in it, what might change about how we do things now?
I’d imagine several things would change.
- We would be far less likely to go there first in a brushfire. This is like our doubt that the String class from our library is fundamentally broken, rather than the index we passed to ‘substring()’. Nobody *starts* by debugging String.
- We would onboard newbs by finding work to do in the rigorous playpen. Both, changing code P and changing code T, both with our assistance & support of course.
- We would orient ourselves *outside* the playpen to buidling code that was readily playpen-suitable from the very beginning. This is the steering premise of TDD.
- As we brought more and more of our code to the playpen, we’d get better & faster at doing it.
- As we brought more and more of our code to the playpen, we would fear deployment less and less.
A question emerges almost immediately: How much is this going to cost?
The answer: a good deal less than you think, because the payback comes at you high and fast. A good deal more than you think, because you have to change how you think — how you feel — about building software.