Chapter 9
Create Technical Excellence

Do you like to practice some form of craft or hobby, such as cooking, woodworking, or knitting? When we practice our crafts, how do we go fast? Part of it is experience with our craft. Part of it is how we create and maintain our environment.

I’m going to use cooking as an example. We need to know what we want to accomplish: is it making dinner or a grand dessert? The plans (recipes) for each are different. We need our tools, such as good knives and pots and pans. We often need interim deliverables, because things need to melt and then cool for desserts. Or we need to sauté vegetables and put them aside for later combination.

Above all, I have noticed that when I am pressed for time I do these things: I read the recipe through a few times so I know what I’m going to do and when. I gather my ingredients so I know I have everything at hand. And I clean the kitchen as I proceed, so I can see my workspace at a glance.

We do something similar with code. We discuss the stories with the product owner so we know what we need to do. We review the code and tests already there to see what exists and what might need to change. And we create tests at a variety of levels to keep the code clean as we proceed.

I’m not saying that producing software products or any other kind of knowledge work is as easy as cooking. However, when we practice our craft, we often need to think about what we will do and how we might do it, and then keep our workspace clean as we proceed.

For software (and hardware and mechanical) products, we spend far more time discussing what we should do (defining and refining the requirements) and reading the existing code and tests than we spend writing new code and tests.

That means we need to consider these ideas to go fast:

• Optimize for reading the code and tests. That often means we need to refactor (simplify) as we proceed.

• Optimize for early delivery to see how we’re proceeding. That often means small stories and continuous integration as we proceed.

• Optimize for creating technical excellence as we proceed. That means we need to test at a variety of levels as we proceed.

Although I’ve written this book for agile software teams, I’ve thought about other possible readers. If you are not a software person, please translate these ideas for your kind of product. Do you read and reread previous plans, schematics, or some other artifact to discover what you need to consider next? How can you iterate on the requirements to refine the work as you proceed? How can you test as you proceed so you know you have a valuable product while you develop, not just at the very end?