3 years ago I planted an 8 foot by 2 foot plot of bamboo. When I did that I dug down 2 feet into the ground. Not knowing how to dig like a professional, it took me a long time – total planting time was 13 hours. 32 cubic feed of dirt and clay takes a lot of work to remove. I needed to dig so deep to put a protective lining around the bamboo. There are two kinds of bamboo you might plant. One kind stays in clumps and doesn’t invade everything. That’s not the kind I planted. I plated the kind that takes over. Thus, I needed to dig 2 feet into the ground and surround the bed with a thick plastic lining. I did all the prep work but then I decided I would let it move into my yard but not into the neighbor’s yard. So I left the front of the bed open.

Fast forward 3 years and notice that the bamboo moved more quickly than I imagined. I’ve been meaning to get to this outside job, but I’ve managed to put it off. I decided to dig a 2-foot deep trench in the front of the bed and add in the missing plastic lining. It took me about 6 hours. Here it is two days later and my hands and forearms are still quite sore. Much of the digging at the top was easy, but as I got deeper, the digging got more difficult. Then I hit clay. That was even worse. I really didn’t have the right tool for the job. I needed a trench digger, but I had a regular shovel, a gardening shovel and a standard spade. These were ok at the top but not as I worked deeper into the ground.

Finally, needing a break, I went to buy more lawn supplies including: pete moss, top soil, steaks, fencing, grass seed, lime, oh, and a 4 inch trench digger.

I was about 20 inches into the ground. The last inch had cost me plenty. The 2 inch bruise on the palm of my right hand (yes, I wore gloves) is one example. That last inch took me maybe an hour. 4 more inches would take me longer than another 4 hours. The trench digger, however, made it more like 15 minutes.

When I started digging I knew I needed to start wider at the top because the trench would naturally get narrower as I worked my way into the ground. This might not be the case if either a: I knew what I was doing, or b: I had the right tools for the job. So I started much wider than “necessary” to give me a little slack later.

That decision was key. Even though I eventually bought the right tool for the job, a 4 inch trench digger, if the trench was too narrow to use it, then I still would have been out of luck. So this decision made it possible for me to use the right tool later.

I managed to finish the trench, line the bed, replace the soil and then get about 100 square feet of yard reseeded.

Other than sore muscles, bruises and the satisfaction of getting something off my well-aged to-do list, what other take aways do I have from this experience?

• Adoption of best practices
• Leave a little slack
• Right tool for the job

Adoption of Best Practices

(There’s a great story of a manager of a Coca-cola plant who’s numbers were far better than his peers. When asked what his “secret” was, he said simply that rather than take a best practice and modify it to meet what the plant did, he instead modified the plant to match the best practice. His secret was not trying to be too clever.

I knew that I should have lined the bed three years ago. I knew that bamboo can spread. There was a well-established best practice on planting bamboo. It was easy to follow. I had everything I needed to follow the practice. I had a 2 foot deep hole just begging to be fully lined. I thought I was more clever (not build here syndrome anybody?) and decided to just line the back of the bed. So 3 years later I managed to spend 6 hours doing something that would have been an additional 5 minutes. If I had just followed the best practice recommended by people who were experts, I would have avoided most of the work I did and all of the bruises, scratches, etc. But I was far too smart to follow the recommendation of someone with real experience.

The best practice when adoption best practices is to adopt the best practice. If you decide to modify a best practice to your local conditions before having direct experience with the practice, the very problems that lead you to consider adopting the practice may be the same thing that will mange to remove all the teeth out of the best practice.

Does this mean you don’t adapt the practice? No. It just means you need to fully understand the practice and more importantly what are its intentions before you start to modify it. When you have direct experience with it, that, coupled with the knowledge of your current challenges, might give you a better chance of coming up with something that works even better. Or, you might just keep with the practice as is.

I had another recent experience with this regarding Uncle Bob’s TPP (http://cleancoder.posterous.com/the-transformation-priority-premise). From my reading of his example, he also practiced TDD as if you mean it (http://gojko.net/2009/08/02/tdd-as-if-you-meant-it-revisited/). I talked to him about this and sure enough he confirmed it. I was working on a “known” problem, a kata. I resisted doing what he had done because it wasn’t what I had done in the past. I even recognized this and mentioned it to him. I decided to just see what happens. Well I ate crow that evening because when I did it, the kata moved quite smoothly for me. In fact, better than it had in the past. It didn’t require as much planning ahead.

What can you do about this? If you can figure out how you tend to resist change, and then notice when you are doing so, you might be able to just work through it. In my case I could tell I was resisting change rather than rejecting the idea – if I slow down a bit and just pay attention I can make that determination, something I learned from practicing Yoga. As for how you can start to learn this, here’s one exercise you could try (http://schuchert.wikispaces.com/AlternatingHandGripExercise). Another idea is to try Yoga. Or, try pausing whenever you find yourself resisting something and ask yourself the question: am I resisting the idea or change. If you’re not sure, then give it a try (and assume you’re resisting the change).

Leave a Little Slack

I stared digging by marking a line where I wanted to put the new edge. I then dug a shallow trench about a foot wide. The extra width was to give me enough room to work. While it might seem like more work at first, in fact it gave me enough rom to move around, attack the dirt at different angles and I used the “extra” dirt to fill a hole dug by my dogs in the bamboo (I hope it recovers).

As I got deeper, I used different kinds of shovels, and the trench became narrower because of the angle I was using to dig, which was related to the tools I used. When I finally hit clay, the larger shovels were too hard to work with both because of the angle but also because of the density of the clay and the amount I was trying to move. I started using a hand-shovel for gardening.

When I bought the right tool it was possible to use because there was enough room for it. Unlike the other shovels that are 10 inches wide or wider, this one was 4 inches wide. It worked perfectly. I was able to take out about 1 – 2 inches laterally and 3 – 4 inches deep at a time. While it might seem like slow going, it was blazing fast compared to my previous attempts.

Right Tools

Growing up on a farm in Iowa, my dad often reminded me of the idea of using the right tool for a job. You might be able to use another tool, but if you use the right tool for the job, it will just go smoother.

My wife bough a few pruning tools last fall. One in particular was much nicer than I might have bought. In the past I would just use the shovel to try and break the roots. This, as you might imagine, is hard work. It will eventually work, but as the roots get bigger, the work grows at least by the square of the diameter (the difficulty felt NP hard (grin) but that’s because I don’t do this work on a regular basis). When I started the trench this time, I used that tool instead of the shovel. To be sure, it required a touch more work. I had to find it in the garage (it was where I though it would be), I had to carry it to the back yard. When I finished the job I had to put it away.

However, it was exactly the right thing to cut the roots that I came across. Trying to use a shovel to cut those roots in the past versus using a proper pruning tool is a great way to have a kinesthetic experience on the use of the right tool for the job.

As I used the pruning tool, I was reminded of this “right tool for the job.” When I took a break to buy more stuff to do more work on the yard, I looked for and found the trench digger. It was a bit expensive. I’ll probably use it for this one job and never again. Even so, within 2 minutes of using it, I did not regret the money spent versus the time saved. This initial impression was confirmed when I moved so much more quickly than I had been moving in more difficult situations. If I never use that tool again it was still the right thing for me to do. If I ever need to dig a trench again, I’m ready for it.

The danger is that you buy a tool for the problem you think you have but while it solves the apparent problem, the actual problem is something else. Case in point, scripting tools for ui-based checking.

I am not against using scripting tools, far from it. However, the secret of checking the UI is to design the code so that most of the logic is unit checkable (http://schuchert.wikispaces.com/tdd.Refactoring.UiExample). The scripting tool seems to be solving the problem of manual checking but that’s a surface problem. A well-design system makes it possible to easily look at it in ways that let you know if it works as expected. We’re used to thinking about headless checking, but what about body-less checking?

Conclusion

Everything is related to everything else, right? Old habits die hard. Insert your favorite cliche here. In a sense, that’s all I’m really saying.

I wonder if working with software allows me to figure these things out more quickly – or at least with less physical pain – or if in fact doing so makes me take longer? I became test infected in 1997. Before that I wrote code to test my code, but I did not keep it around as a living artifact. On the surface it appears to take more time and effort, but in practice doing so pays dividends.

Moving to practicing TDD came later. When I started trying out TDD, I though it was a bit silly. When I originally read an article about Inversion of Control (http://martinfowler.com/articles/injection.html), I though “meh.” When I was originally shown Mozilla 0.8, I though “hyper cards over gopher net, meh.” In fact, I can almost predict the viability of a technological idea as the inverse of my initial impression to it.

The cost of being wrong isn’t too bad if, as I often do, change my mind with evidence. In the case of physical labor – planing bamboo – the real physical pain of doing it poorly has a much more real feeling consequence and maybe works better for me as a way to reinforce things I already know.

When you work do you leave a little slack? Do practices like TDD give you a little slack? When you follow those practices, do you try to get a “pure” experience before adapting or do you adapt from the beginning? Are you using effective tools to solve your actual problems or do you notice tools that solve an apparent problem but simply introduce worse problems than the one they were originally meant to solve?

I have fewer problems with that these days: First, I don’t try to cover it all. I just try to cover some of language highlights. More importantly, using a unit test framework makes it easy to experiment.

On the OOAD front, the problem I used to have was trying to “help” the students by pointing out mistakes ahead of time, so they wouldn’t suffer the same mistakes I’ve made. That was fundamentally wrong on my part, well intended, but just flat-out wrong.

People need to see mistakes and even make mistakes to move forward. I’ve personally learned probably most of what I know based on either making mistakes or observing other mistakes – ones I would have committed myself if my customers had not already done so themselves – thank you for that.

I’ve recently discovered myself making this same mistake again. In this case it has to do with enforcing code coverage to get people to write tests. I used to think this was a bad idea, and maybe it is, but even bad ideas can have utility – context, context, context.

How can this possibly be a bad idea? Well when this happens, developers tend to write tests with few checks that are heavily implementation-oriented. If the production code is written first, which is more common, it often has high path (cyclomatic) complexity. What ends up happening is developers write complex production code for many “just in case” scenarios, the code has many paths, they are told to get 80% coverage and so they write tests to verify that all the paths of their code have been executed.

Of course, how many of those paths are essential versus incidental isn’t typically considered. Since the tests are written to drive coverage, and the underlying code is probably overly complex, the tests tend to be heavily implementation-oriented rather than intention oriented (or scenario-based). The tests are hard to write, harder to read and even worse to maintain.

So up to a few months ago, my advice was to not enforce coverage. But a great theory is often destroyed by data. I’ve had 2 customers recently enforce code coverage on new development. Both of them experienced something like what I expect would happen. They implemented coverage standards, implementation-oriented tests got written and developers were having problems with writing unit tests. However, something else more important happened. Even though the tests were hard to maintain, many of the developers started to get test infected. That is, they started to be convinced that writing unit tests was valuable and now they needed to know how to do that more effectively; rather than this being the destination, it was a step in an ongoing journey. (Another example of a mistake I make, confusing a process for one of its events.)

To me, someone who is writing tests, thinks they are useful and is now ready to learn how to write them more effectively is easier to work with than someone who has not written tests, don’t think they add value and certainly are not their responsibility.

So it appears this “bad practice” has merit as an intermediate step in a longer learning arc.; one possible path through the murky testing waters. Did I make these kinds of mistakes? I’ve never been in a situation where I was told to have some % coverage, so not exactly. However, have I written implementation-oriented tests? Yes. Have I written tests with few or no checks? Yes. I still do sometimes, but much less so than in the past. Just now I do so consciously rather than out of a lack of options.

As I see it, I committed several mistakes I’ve made in the past. First, trying to “help” people by giving advice which would allow them to avoid mistakes I’ve made in the past. Maybe those mistakes are a necessary rite of passage for some people. Another mistake I made was thinking of the learning experience as an event rather than a process. Finally, while I might be tangentially involved, ultimately someone else’s learning is their learning, not mine. They need to do what they need to do. I need to be available if necessary, but otherwise keep my agenda out of it!

Take in the context of a class, learning really doesn’t stop after a TDD class, or coaching. Some might argue that learning doesn’t start UNTIL the TDD class is over – I could make that argument myself. In any case, I was looking at my involvement as “the learning event”. As I write this, I realize just how insane that really is. I wasn’t aware of my mental model until recently; now that I am hopefully I can fundamentally change how I approach this situation going forward.

What are some other “don’t do’s” you’re aware of that make sense in the context of a process, but not as an end or goal?

I would like both for and against. I prefer research or experience rather than rants, though if the rant is funny…

Thanks!

—

(This is taken from a recent email I sent.)

Start Here

• http://en.wikipedia.org/wiki/Pair_programming

Good overview and sites studies.

Then here

• http://accu.org/index.php/journals/1395

Here’s a good Snippet from that site:

A 1975 study of “two-person programming teams” reported a 127% gain in productivity and an error rate that was three orders of magnitude less than normal for the organization under study. [Crosstalk]

Pairing in Education

• http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.89.6834&rep=rep1&type=pdf

Other Articles

• http://www.stsc.hill.af.mil/crosstalk/2003/03/jensen.html