Friday, July 29, 2011

Controlled Fall

Humans have evolved over the last 3 to 4 million years to walk upright constantly on two legs. While many of our primate relatives and some other animals are able to walk for short periods of time, we are almost uniquely bipedal.

It's fascinating to watch a baby learn to roll over, move about in one spot, start to crawl, pull themselves up to standing, move while holding on to items such as furniture, stand freely then finally take those first tentative steps. While each of those steps occurs, the child is building neural pathways like there's no tomorrow to help them coordinate their movements and the signals coming from their inner ear that tell their brain which way is up.

The act of walking is interesting in and of itself - it's actually a controlled fall. We lean forward a bit, and one leg moves out in front. If not for that leg, we'd fall flat on our faces. Somewhere deep in our DNA, something triggers the growth of paths in our brain that builds the progression from rolling over to walking, increasing our ability to balance ourselves upright all the while.

Of course, a few short seconds after a toddler learns to walk they want to start running! We often see these small children careening out of control into furniture, walls, pets or anything else that gets in the way. Running is an extension of walking which takes much more balance and coordination, i.e. much more control over the falling process. Children gain this control at a startling rate - within a year of learning to crawl, a child will be literally running amok, and any house pets will be eagerly searching for high ground in order to stay safe.

To prevent catastrophic injuries, we make the child's environment safe. We put gates on stairways to prevent that controlled fall from occurring in mid-air. We add soft cushioning to the corners of tables. We move plants and decorations from once inaccessible places to somewhere out of the reach of this now very mobile toddler.

We make the environment safe for the child to run around. Whether we want them to or not, they are going to go fast.

The only way to go fast is to be safe. *

Coaching Point
I've mentioned before that, like toddlers, teams are obsessed with going fast. Like toddlers, this is not a bad thing most of the time. Like toddlers, moving fast can mean that a team will bump their head on the corner of a table. They might fall down the stairs. They may simply lose their balance and fall. They may go places that they shouldn't before someone can stop them. So, the environment in which a team works must be made as safe as possible in order to prevent injuries while going fast. How do we do that?  Test-Driven Development (TDD).

TDD at the Acceptance and Unit levels keeps the floor clean, protects the corners of tables, puts gates on the stairs, moves plants, gets the pets out of the way and adds a layer of foam cushioning to the floor. I realize that the concept behind TDD is completely foreign to pretty well anyone who hasn't tried it (and many who have), but after a decade of using it I can say without a shadow of a doubt that it's the best way to develop software that I have encountered in the 30 years since I wrote my first program.

When I first learned the technique in early 2001, it took 3-4 months of constant use to move from "this is just crazy" to "this is kinda cool" to "this is fantastic". Like learning to walk and run, it doesn't happen overnight and every person's progression is different. You will hear people complain that they're slowing down because they're writing twice as much code because they're now writing tests. Experienced developers will rail at having to write such simple code to make a test pass, i.e. it would be faster to take bigger steps. Everyone will complain about how difficult it is to do TDD with legacy code - it takes so much time to be able to write the tests to enable the refactoring required to untangle the mess of code that was written without tests.

All of the complaints revolve around wanting to go fast. Yes, you have to write more test code, but the benefit far outweighs the cost in the form of persistent validation of our assumptions about what a particular piece of code should do. Yes, you take small steps, but in doing so you will very likely write less code, certainly less complex code and code that's inherently testable as a result. Yes, legacy code is a pain, but if you want to use it safely you need to get tests in place.

After all, the only way to go fast is to be safe.

* Credit goes to James Grenning for this aphorism. "Uncle" Bob Martin has used a similar term: "The only way to go fast is to go well."

No comments:

Post a Comment