Impatience

Larry Wall once stated that a good programmer has three chief virtues, Laziness, Impatience, and Hubris. 

I struggled with that quote for quite a while after I first heard in in 1994. Eventually I got his meaning and I can see now how it relates to some of the things we do in the Agile/Lean community. Specifically impatience. 

We talk a lot about doing experiments, and making things big and visible, and measuring things. Some of us even execute on those things with great regularity. Many more of us do not. It seems like we spend a lot of time giving lip service to metrics and retrospectives and vastly less time actually executing on those things. 

As Captain Jack Sparrow would say, 'The problem is not the problem; the problem is your attitude about the problem'

When we see problems we make up measures and experiments to try to solve them. Its a great idea, but I think we often wait too long to see if our solutions work. That is, we are too patient. What we should do is identify one or more solutions, pick the one that is most easily implemented, and then go do it. However, we need to do this with some amount of control, otherwise we're just flailing around like a fish on a hook.

First thing, we need to establish how we know we've resolved the problem. For example, if the problem is something like following coding standards, we know the problem is fixed if the number of formatting issues is reduced to zero.

Then we need a time box, by when will this problem be solved. Lets give it a week. We'll tackle this issue and solve it with a technique by next Monday. 

OK, we have the only two things we really need to define our solution. Now we can spit ball a bunch of ideas about how to solve this problem in a week. Lets say we come up with this list;

1) Setup a static analysis tool that alerts us to violations when we build the software, CI should fail the build if there are violations
2) Have code reviews for every single commit/merge that examine the format of the code
3) Abandon the code formatting rules
4) Configure all the IDEs to format the code when saved

So, given those four options, which one can we implement in a week? Probably all of them, though number one might be hard to do that quickly depending on your language of choice and tooling.

Which of those remaining seems likely to succeed? Clearly number three is a non-starter, if code formatting wasn't an issue we wouldn't be having this conversation. 

So we have two real choices, code reviews or automation. Can our IDE format code for us? Probably, so lets try that one first. 

Now I picked a pretty simple (but overly common) problem to illustrate how you'd get to a resolution. I doubt any of this was a revelation to anyone. But we're not done yet. Once we have put this change in place, we need to check back and see if it worked. So, next Monday we need to see if it worked by looking at the count of formatting issues we've had. If the number is lower than when we started we're on track. If its already zero we're done. If by some chance the number went up we need stop and try again. But if we don't check the result, the experiment was for not.

One of the things I see many teams do is respond to the conditions of their environment but never follow through on their attempts at resolving them. This may be OK in the small world of a project. Using the above example, violations of the code formatting rules reach zero, everyone implicitly accepts this and they all keep working. Consequences, probably zero. But what if the issue were more complicated, for example, defects escaping into production? Or failures to respond to operations requests. Production outages? Or the cost of operations increasing due to the proliferation of empty 250Gb databases. In order to resolve any such issue we actually have to remember to conclude the process by going back and looking at the results of our experiments, and the sooner the better. Thus, impatience, or at least one aspect of it.

Getting feedback quickly, and responding to it, is critical to success.