Saturday, March 27, 2010

On chopping trees and developing software...

Today my wife and I went to visit with some friends of ours who live in the middle of the Mount Baker National Forest. They have a cabin and some property in an old mining town there and every time we go to visit there are some tasks that they could use some help in doing (and we love it).

Today a 25 foot evergreen tree, that was standing alone in the middle of the backyard, had to be felled. This meant I got to use power tools, specifically, the chainsaw.

Let me tell you, me and power tools haven't really spent much time together. My dad had a garage full of them when I was growing up, and he and my uncle could take cast off wood and make clocks, benches, shelves, you name it. And not only wood, they worked on electronics, cars and even designed a new musical instrument (not many have heard of the Harpsitar, but Stevie Wonder played it once). I watched and wondered and admired, but I rarely participated, and not because they didn't bring me in, they tried, but I just didn't like it. I think I was too scared of doing something wrong, so it was easier just not to do it at all.

Back to the tree, and the chainsaw. D_ had it all planned out, tie a rope two thirds the way up the tree, then about four feet up he cut out a wedge to encourage the tree to fall in the direction he wants. Then he tugs the rope along the desired path line while I make the finishing cut (with the chainsaw) on the tree ... and TIMBER!!!!

The tree fell about 30 degrees off the desired line, which was not ideal, but it was better than the 75 degrees off the line it would have fallen if cut right through with no rope and no guiding wedge (that would have killed a greenhouse, this way only hurt a small maple tree, and more importantly did not hurt myself or D_). Once the tree was on the ground we cut the remaining four feet down then marked off the tree in sixteen inch sections and proceeded to 'sausage' it up. We produced about a quarter of a chord(4'x4'x8') of wood, neatly stacked, which is about a weeks worth of heat for them next winter, not a bad afternoons work.

But what does this have to do with developing software, you may appropriately ask, since I did title this post the way I did. The short answer is not much, on the surface, but I think there is a good metaphor in there and I am going to try to dig it out.

I think that developing software can very much be like chopping down this tree. You make detailed plans based on past experiences and best estimations and then when you put the plan into action what you get is not exactly what you set out for. In the strictest sense that's a failure, but failure is really just another chance to learn on your way to success.

With 25 feet of tree chopped into 16 inch sections there were plenty of cuts to be made, especially since all the branches needed to be chopped off of the core logs. So I got to fail a lot, in order to get to the point where I was succeeding regularly. You see you have to learn to use the chainsaw to your best advantage, and you have to learn to be aware of surroundings when you use it (no blood was shed by anyone in this learning process, thankfully).

When cutting a branch off the core, you use the tip of the blade to slice it off like skimming butter with a butter knife, not like a potato peeler digging out a eye. When cutting the segments you want to let gravity work for you, so if the log is on uneven ground cut on either end of a mound first so the segment you cut wants to fall away from the saw. If you have to cut into a mound, watch that you don't saw dirt, or rocks, or wires, it's no fun, and it dulls the blades. Have extra blades ready, for when you dull the blades. When cutting a big log, push the blade all the way forward so that the teeth at the base of the chainsaw grip the log so you can pivot the blade through the the tree and move down in stages. Don't try to force it or turn the blade, or hold the blade in space and 'saw' back and forth like you would with a hand saw, all of these will cause the chain to seize up and the motor to run hot. By the time I did the last half dozen cuts the chainsaw and I were a well oiled machine, but I had to 'fail' several times and make a lot of the mistakes listed above in order to figure out what works well and would make me an efficient chainsaw operator.

Well the same goes for Software Development, substitute a product release for the 25 foot tree, and construction sprints for the 16 inch sections and you have yourself a real metaphor.

A team has to learn to 'fail' together in order to learn how to become the well oiled machine that you want them to be. They will sometimes develop what was designed, but not what was requested. There will be bugs based on misunderstandings and miscommunications, or even oversights. There will be resistance to learning new techniques, and estimates based on prior experiences that do not apply to the current project and are too long or too short. There will be conflicts of kinds personal, professional, scheduling, and resource availability. And all of this is normal and good for a team to go through as long as it does not become a chronic condition, as long as the team makes it a regular practice to learn from these failures and incorporate what they have learned into the next iterations.

So in the course of one afternoon I went from being a chainsaw newbie to a person who could make most cuts where pointed and chop through a trail blocking log with little fuss. Cutting wood with a chainsaw is a relatively easy task, developing software is a lot more complex, if less physically strenuous.

A good team can go from a group of random engineers to an agile quality software developing machine in the span of a major release or three. But they have to earn it and learn it through failing together and preventing repeats of those failures so that future iterations contain a lot more WIN and a lot less FAIL.

It can be done, and fun can be had while doing it. Providing heat for a week in the winter, or a SaaS Web Application for managing IT operations you have to be willing to risk doing something wrong, and learn from the times you do, so that you end up doing things right a lot more often in the end, and remember to have fun while doing it.

1 comment:

  1. Way to go Juan! You inspire me. Let's blog about how software qualiity == Great team communication. I made a mind map recently (who showed me that?) about quality and I have something to share. I'll send you link.

    ReplyDelete