After the Agile2011 conference, my wife and I took some great hikes in the mountains of Utah. We were careful as we navigated the slot canyons, rushing streams, and falling water. We were careful, we did not want a mistake to cause an injury; but we have no fear of height and love adventure. After a few days of hiking, our skill grew and we worked the terrain more quickly and safely.
I’ve described TDD using the analogy of stepping stones to cross a river for years. Here’s a Utah stream coming from a slot canyon.
You can see there are a few ways across. It’s not a straight path, but with a few careful steps you get to the other side, keeping your shoes dry.
Over several days of hiking, I discovered another metaphor for TDD, often thought of as a very careful way to program. The careful way is the fast way.
With the temperature usually around 100°F, we did most our hiking along cool mountain streams. When you hike a mountain stream and its 100°F you don’t worry about getting your feet wet. Well, at first I did, as I decided to protect my brand new hiking shoes. We had a lot of river and stream crossings to do, and within 10 minutes, I gave up protecting the shoes and decided they could protect me instead. There is no avoiding getting wet as we approach and cross this waterfall.
Notice those green Agile 2011 water bladders compliments of the Scrum Alliance.
We also brought along hiking sticks, which proved to be very valuable. Here you can see me fully outfitted: water tolerant hiking shoes, hiking stick, and field modified Agile Manifesto Author shirt (compliments of Agile2011, thanks). (That guy in background in his speedo really messed up a few more pictures)
After many crossings, it became very evident that having the right equipment and working the river carefully were keys to no scrapes or twisted ankles and generally keeping dry what is possible to keep dry. People without the right equipment were tipping and slipping. Some went down. Some were bleeding. My wife and I never went down. We were faster than the ill prepared. After several hikes, our pace quickened. At first we were tip toeing, and later cruising through the shallow waters.
In life we know the careful way is the fast way. (How has this lesson been forgotten in business and programming?) How would you cross this stream?
Of course the fast way is to just run across the fallen tree. Sure some people could do that, but even if you could, would you have your spouse, children or mother do it that way. Unless your family is on vacation from Barnum and Bailey Circus, you probably won’t take the log. You’ll go carefully through the stream.
Let’s just say you are one of those super programmers that can get their code right the first time. Oh yeah, you also never make mistakes when changing it later. (That should weed out 99.999% of the honest programmers.) You don’t need TDD, or do you? Maybe you’d like it if the rest of the team wrote tests, but you don’t need them. What example are you setting? Will those that later follow you be able to dash across the fallen trees? Maybe you should do it for them (but I digress, back to the river).
There is more danger in this next river navigation maneuver. One of mother nature’s flash floods put a tree over this waterfall. People augmented her work with hammer, nails, 2x4s, anchors and ropes.
Working up or down this bad boy means using all your limbs. Running up or down this ladder barefoot is not a good idea. The walking stick does not help, but the ropes sure do. (Know your capabilities; know your tools.)
Navigating mother nature and companies’ handy work is like changing legacy code. You must work carefully as the consequences of a mistake are very costly. You need to be quite careful; tools help.
Whether you are hiking or coding, have and use the right equipment. Don’t take my word for it, let’s see what Mike, a random man in the stream, has to say.
Mike would not hike the stream without his hiking stick, even though it is extra weight to lug around. Those water logged hiking shoes also are extra weight to carry. But they help maintain a steady pace. (I saw one guy trying to do the river barefoot with no stick; his progress was painfully slow. Another guy, without a stick, slipped on a rock and ended up in natures cold Jacuzzi.) As we got better in the streams, we got faster. We altered our pace as conditions warranted. We made steady progress and had fun!
When I show someone how to do Test-Driven Development, the reaction is often, “It’s so slow! It’s faster to write all the code and then test it. We don’t need and can’t afford all those tests.” I’m not alone when I disagree with this position. In TDD we are very careful. We have a direction, and anticipated path to our goal. Each move is thought out just in time as it gets us closer to our goal. We prevent mistakes. We are not paralyzed trying to plan the optimal solution, rather we are discovering a good solution, the best one that meets our current needs.
In rushing river hiking, we can move toward our goal. Each step is probed to with a toe or hiking stick so we have a good idea of what the step will bring. Your shoes, walking stick and ropes are your safety net. We don’t just try it and see if it works. We make each move deliberate.
Test-Driven Development is a careful way to work. The careful way is the fast way. Get good at being careful and then you can go fast.
The fallen tree across the river reminds me several of my trail runs:
I’ve gone running with a few of my buddies and have been tempted to take the “fast way” and rush across the tree.
It might work out well for the first guy – but the runner behind him is always in for a treat.
As anyone who’s done this knows, wet shoes make for a slippery crossing. The slippery mess made by the first guy or gal makes it doubly difficult to get across the log without a spill. Even if the second or third runner makes it across, the more mess made, the more risky the path becomes.
So on that note – just because “the fast way” might seem doable – don’t. If you do, you’ll probably make it harder on the next guy 😉
This is true of TDD too. Maybe you can write code that does not need tests, but those that follow you (including yourself) will need them.
thanks for the comment!