Once upon a time, people developed software using a linear approach. They would carefully write up a 30+ page specification for the product, and then they would spend a long time – several months to years! – developing the product to match the specification.
Then, of course, they would discover that the market had changed, or they had guessed wrong when they built the feature.
And they would sigh, go back to work, and develop another lengthy specification for the next release, which would come 6-18 months later and have the exact same problem.
And so everyone suffered. The software engineers wasted their time, and their customers got products that didn’t meet their needs.
Then the developers realized that there was a better way to develop software. They said, “We’ve spent decades trying not to make mistakes in the product specifications. But we always make mistakes, and because it takes us 18 months (and millions of dollars!) to know that we’ve made a mistake, our failures are painful and expensive.”
“So what if, instead of spending pointless hand-wringing hours trying not to make any mistakes, we devised a way to make the mistakes we inevitably make cheaper? What if we could find out about them faster, so that if we’re going to fail, we fail faster?”
They decided to change. They began to design in small chunks, a little piece at a time, rather than writing a single monolithic specification.
Now, instead of releasing enormous software updates every 18 months based on an encyclopedia-size specification, software development teams produce software in short development cycles. (Two weeks is considered optimal.)
At the end of each development cycle, the team demos their software to the customer, and gets feedback. Based on that feedback, they decide what to build in the next cycle.
The advantages of working this way are pretty obvious: you can only get so far off-track in two weeks, so mistakes are cheap, and because you are constantly getting feedback about your product, you can build something that will be much more useful to the customer. Most software teams are now using variants of this approach.
How does this apply to craft?
Well, craft artisans and software engineers have a lot in common. Both are doing creative work, both have an element of uncertainty in that work, and both need to be flexible about change in what they are building. So industrial new-product development methods can benefit to artisans, too. The particular principle I’m thinking of right now is this:
At first blush, this seems silly. Why would you want to fail faster? We all want to succeed, don’t we?
But the truth is that mistakes are inevitable. What we want to avoid is expensive mistakes – ones we don’t find out about until the very end of the process, when it’s too late, or very expensive/labor-intensive to correct. We’ve all had projects that turned out to be disasters – like the mohair coat I spent months constructing, only to discover that the buttonholes weren’t placed correctly, so the coat gapped open!
The point of “Fail Faster” is that we shouldn’t try to avoid making any mistakes. Instead, we should try to make our mistakes as inexpensive as possible – “Fail faster!” means identifying your mistakes – aka failures – faster, so they will be quicker and easier to fix. The point of the shorter development cycle is that it allows discovery and fixing of mistakes much more quickly than if you did the whole thing at once.
Now, how does this apply to craftwork? It’s very simple.
Sample early and often
Sampling is important in a project precisely because it allows you to fail faster. As an example, consider this image, a Photoshop mockup for a fabric I was designing:
I didn’t like this mockup, so I didn’t use that design in my project. But by sampling it quickly in Photoshop, I discovered within ten minutes that I didn’t like it. So that design error was far less costly than if I’d sat down and woven a physical sample, or, worse, woven up an entire piece! I “failed faster” using this fabric simulation, and it saved me a lot of time and grief.
Sampling is a way of reducing the cost of errors. Instead of developing a monolithic project to a set of untried specifications – basically, gambling everything on a single throw of the dice – sampling allows you to develop things iteratively, trying out new ideas and fixing mistakes in short development cycles. The bigger the project and the more uncertainty around it, the more value there is to sampling – to failing faster.