One of the biggest challenges for someone experiencing TDD the first time is working in the small steps. The small steps of TDD appear to be an independent discovery of John Gall’s observation described in the Systems Bible:
As Kent Beck told me years ago, after the first test passes, you’re in maintenance. From that moment on we’re evolving the behavior of the product, while keeping all previously working behaviors working.
John Gall also weighs in on designing a complex system from scratch.
When I first read that statement, I thought, what is he talking about? My team was successful a few times with waterfall. We got the system to work, eventually. But how did we do it? Over the years of doing TDD, I realize Mr Gall is correct. We went back to small steps; the small steps of debugging.
When push comes to shove, people chasing bugs are perfectly comfortable with small steps. We’ll ask ourselves what does this line of code do? Maybe we log intermediate results; soon the debug code outweighs the production code. Sometimes we’d get out the debugger and single step. Some even write a test program that tries out the scenarios. In all these cases where do we start? We starting from a simple case and build confidence one small step at a time.
If you were building a circular buffer object and it did not work, you’s start with the basics. Is the FIFO empty upon creation? If you put something in, is it no longer empty. Can I get out the thing I put in? Is it empty once I do?
The person doing debug later programming knows the small steps once they are forced into them due to the reality of defects in their work.
So people struggling with the small steps of TDD, maybe you’ll be better off doin them proactively to prevent defects rather than reactively in response to defects. You already know small steps.
I’ve heard people say that software should be like building. You make a plan; buy the materials; and build it. Would remodeling be like new construction? Kind of. You make a plan, find a contractor, agree on the specs, order materials, demo (demolish) the unwanted parts of the building and build it out. Simple step by step.
Does it go that way?
We are remodeling a two bedroom apartment. It has not had a major renovation in decades. The design and planning process was all very orderly. Though everything changed once the demo (demolition) began. Within minutes I had to react to a series of unknowns that could only be known once the project started.
As soon as the cabinets came down, a long hidden and slow leak reveled itself behind the sink. This was like an unknown and unknowable requirement. The cabinets had to come down to reveal that need.
Next, pulling up the bedroom carpet and removing the baseboard revealed drywall damage. Another latent defect! There was a leak in the outside wall, somewhere. Was it the foundation/upper wall boundary? We dug a hole to inspect the foundation wall top. It looked fine. Then we directed a forceful hose to the foundation top, testing a hypothesis; no water appearing on the inside floor. We had a bug hunt. What is the cause of this mysterious behavior. After more drywall was removed the root cause was discovered; it looks like the leak originates around the window. The hose reveals the leak’s location. Bug found!
Our plan also included opening a wall to create a built-in workspace and closet. As the wall was demoed, a electrical junction box lay hidden right in the middle of the wall. The wall plate had been painted over for years. This is essentially an immovable object, as the junction box is anchored in concrete. Metaphorically it’s binary code, where the original source code or tools no longer exist. We’d have to create a work-around.
Notice the just-in-time design on the wall! No formal UML needed.
I am not really surprised by any of this. Developing software prepared me to expect surprises in a project of all but trivial complexity. Remodeling is a lot like software. A plan of attack is good, but don’t expect the plan to stay intact; You’ll have to react.