On Monday Evelyn and I went to the Agile Denver meeting in Denver. Since much of our Linux Consulting business isn't something you can really plan, this was something we were really looking forward to. Dr. Lee Devin is, I gather, a theater teacher. As I heard recently, there are few project deadlines firmer than opening night.

One of the main topics of the presentation was the distinction between planning and preparation. Planning is what you do to make sure you're ready for what will happen. Preparation is making sure you're ready for what might happen. By means of an example, imagine I'm giving a presentation on Python. Slides and hand-outs would be part of the planning. My having been using Python as my primary programming language for a decade would be preparation.

It seemed to me that Dr. Lee Devin didn't really know how talking about the theater for 90 minutes could be applied to software development. I say this, in part, because he admitted as much towards the end. That's not to say I didn't find the talk valuable. I do however think, based on questions at the end, that some of the audience didn't know how to apply it to themselves however.

I think that in this case the talk could have been probably half the length it was, and instead of 10 minutes at the end for questions, using the other half for them. In fact, it probably would have been an amazing session if he had presented for 45 minutes, and then stepped out of the way for the majority of the questions, letting the audience figure it out for themselves. Using questions to guide the talk, but then facilitating on collaboration within the audience to figure out how to apply it.

The presenter would always bring the answers back to the theater, because that's what he knows. Fair enough... I felt that I had something to contribute on answering some of the questions, but didn't really feel I had the space to do so.

Boy did the presentation really fire me up to try an even more audience-driven presentation. Maybe I'll try something like that at Bar Camp next weekend.

Another thing I did with this presentation was that after it I stopped Evelyn and asked her what she got out of the presentation. I started a dialog on it. We have been doing this some after watching "Nerd TV", and it can really help make the experience much more valuable. That's another thing I want to try to do more in the future.

One thing I took from the presentation was that we're doing pretty good for the Linux consulting side of our business. Evelyn and I often have discussions where we try to figure out how we could do better planning (using Dr. Devin's phrasing) for when someone calls us with a problem. The problem is that, as a consultant we fairly rarely get "cookie cutter" requests.

Even if some of our requests are similar (for example, we're currently working with clients to set up 3 Linux High-Availability clusters), they often differ substantially on the details (these 3 clusters could hardly be more different).

So, what is it we're doing so well? It's the preparation side... We do a lot of things which just get us more familiar with things so that we can solve the unusual problems. Knowing how to attack problems we haven't seen before. What avenues of investigation are likely, and what are futile. We spend a lot of time, between community service tasks, experimentation, and personal projects, doing things which aren't directly applicable to a client, but which help us solve client problems quickly.

Another thing that echoed in me was the idea that you shouldn't try to reject things that didn't work out. Don't pretend they didn't happen. Instead, embrace them and make them a productive part of your personality.

One example of this is something I've recently started doing. When doing a dangerous command, such as "rm -rf" or "chown -R", I will try to give a fairly concrete path. Instead of "chown -R jafo .", or "rm -rf *", I will do "rm -rf /home/jafo/projects/wifiroamd-testdir/*".

One thing is that you don't have to know where you are. The command is just as safe to run after "cd /home/jafo/projects/wifiroamd-testdir" as it is after "cd /". Now, that said, I can type pretty fast, so typing an extra few dozen characters isn't a big deal. Even if you do a "pwd" and then paste it in to the "rm -rf" command, you have another benefit... Have you ever accidentally run the wrong command from your history? I sure have... If you give the full path, it's much less likely to be a big deal if you accidentally re-run this command at some later point when you're doing something else.

Of course, the preparation for these problems is having known good backups...

This goes directly to one of the audience questions: "What is the agile software development equivalent of method acting?" My answer to this is: Spend time playing with your technology. I don't run a Debian-based PC firewall and CentOS-based storage server at home because I can't get off-the-shelf components that will do this. I do it because it's something I like doing, and it gives me an opportunity to play with various technologies. Google encourages employees to spend 1 day a week working on personal projects.

Orkut is the result of method acting. :-) For those of you that don't know, Orkut is the result of one employee's 1 day a week spent on personal projects.

Obviously, I found I took some fairly valuable things away from this presentation. Part of it is that we should stop worry about having workflows for more tasks, because we're doing really good at what matters in the consulting side of our business. For the things that really are cookie-cutter problems, we do have pretty good work-flows. These are important, don't get me wrong. Workflows can make tasks go faster with fewer mistakes or missed steps. We use them in most places where we can.

Business decisions can be pretty tricky at times. Having more work-flows seemed reasonable enough at the time, but that only takes you so far... Without cookie-cutter problems, you just have to be prepared to come up with the right solutions when the time comes.
(Post Reply)