I used to paint many years ago, and I loved it. In the last few years I have not really touched my brush. Last year when I wanted to get back to running after an eight-month break, Haruki Murakami’s fantastic book, What I Talk About When I Talk About Running helped me to get back to it.

My last painting. November 2005

A few weeks ago I decided to start painting again and started reading Art & Fear: Observations on the Perils (and Rewards) of Artmaking by David Bayles and Ted Orland. This is a book about the way ordinary art gets made, the reasons it often doesn’t get made, and the difficulties that cause so many artists to give up along the way.

What I love about this book is that it uses art to talk about life. You can apply its lessons to almost anything. While reading it, I could not stop thinking about the parallels between art making and the “craft” of software development.

The writers talk about fear of failure, imagination, vision, execution, and joys of building something that only exists in your imagination in the face of uncertainty. They explore artwork’s life cycle, and to me, it was very similar to the life cycle of a software product. “Imagination is in control when you begin making an object. The artwork’s potential is never higher than in the magic moment when the first brushstroke is applied, the first chord struck.”

This is very true whenever we start a new software project. We always strive to build a product with best product/market fit. We want to it to be the most organized, well-written, loosely coupled, highly cohesive code base ever. The imagined code base in our heads is always perfect. The thought-up product is always the best fit for the market. However, problems begin when we humans have to implement it in our imperfect ways. “Finally, at some point or another, the piece could not be other than it is and it is done. That moment of completion is also, inevitably, a moment of loss—the loss of all the other forms the imagined piece might have taken.”

We can never get it to perfect at the outset form, but we move it closer and closer with each round of releasing, testing, and refactoring. After all, “to demand perfection is to deny your ordinary (and universal) humanity, as though you would be better off without it.”

Perhaps the single most important trait of a team building high-quality, fit-for-market software product is the concept of iteration—and its associated learning. In lean cycles we know this as the build, measure, and learn loop.

There is a famous story in the book that resonates nicely with this concept:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot –albeit a perfect one– to get an “A”.

Well, it came grading time, and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes –the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

This story is the best way to explain the build, measure, and learn loop. You have to build many times and release many times to get better at the releasing software. The story echoes nicely with one the most important principles of continuous delivery. If something is difficult or painful, do it more often.

To me the most important phase of the loop is learning for from your work. “Art is like beginning a sentence before you know it’s ending. The risks are obvious: you may never get to the end of the sentence at all—or having gotten there, you may not have said anything.” Building software is very expensive, and it is important to take steps to reduce risks. And this is where learning becomes useful. We should use this learning constantly to course correct and make sure that we build a product that actually says something!

I have yet to start painting again. But I really enjoyed this book. I’m sure at some point I will paint again.