I’m a woodworker. I love to work with wood, and I truly enjoy the sense of satisfaction that comes from the work I do. I think this is why the software Craftsmanship movement rings true for me. I find many of the aspects of the craft of making things out of wood to fit perfectly with the craft of creating software. Most of these parallels are fairly obvious, yet they are still quite valuable to explore. This time, I’d like to relate a lesson that has stuck with me for years now. As with so many things, it begins with a story…..
My best friend and I like to go to a woodworking show every November. Some of the most prominent names in the craft give lectures and tutorials, and we get to try out cool new tools. At one of these, a very well-known writer on woodworking gave a lecture on “Best Practices”. He apparently had not known that he was going to be giving this lecture, and turned it into a bunch of tips and tricks. He then, about ten minutes before the end of his allotted time, stopped, took off his glasses and looked at the audience. He said “there’s something else I want to talk about today. Give yourselves a break. How many of you have spent hours on hours working on a piece of furniture, only to be upset with all of the little mistakes along the way. You finally say you’re done, and while other people are admiring your work, you only notice the one little chisel mark that you just couldn’t sand out. Look, it is never going to be perfect, and you are going to frustrate yourselves if you can’t accept that.”
So…how do we know what is Good Enough? How do we know that this piece of software is going to be sufficient? Well, of course in the Agile world we start by saying we will have automated tests for everything. Automating those tests up front is of course a great way of driving our design and a certain level of quality. The other piece of the puzzle though is to make sure we are not signing up for more than we can handle. Whether we are using Lean/Kanban or Extreme Programming, we are designing our software process around making sure that we have the time to do what we want to do, without cutting corners. Far too many problems arise out of trying to cram that last feature in, or making a compromise on a design flaw because we just don’t have time to “do it right”. So between Test Driven Development and agile techniques to manage work in progress, we have a nice set of tools that will help us stay on the right side of the quality equation.
But there is one more thing we need to do. We need to learn to let go of this crazy notion that if we engineer something enough, if we do enough code reviews and enough design sessions, we will be able to make perfect software. There is no such thing. We want to make software that works well, doesn’t fail at inopportune times, which could be as simple as while I’m trying to write a document or as major as while I am trying to land an F/A-18 on a carrier deck, and that people want to use. When you see that little chisel mark, ask yourself whether you need to put extra time and effort into fixing it, or is it something small that really doesn’t affect anyone. So absolutely, make it the best you possibly can, make it beautiful and functional, but remember that until it is actually delivered to a customer, it is worthless. Set yourself some parameters around what is Good Enough for this project. Don’t set ridiculously high standards because it sounds good, but be pragmatic.
And for Heaven’s sake, give yourselves a break.