I’ll begin this post with a parable:

Once upon a time, people developed software using the “waterfall” model.  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 30+ page specification for the next release, which would come 6-18 months later and have the exact same problem.

And so the people suffered, until, about twenty years ago, someone realized that there was a better way to develop software.  They said, “We’ve spent decades trying not to make mistakes in spec’ing out the product.  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!  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?”

And thus, the Agile development methodology was born.  Instead of releasing monolithic software every 18 months based on an encyclopedia-size specification, software development teams produce working software in short development cycles (two weeks is considered optimal).  At the end of the cycle, you demo your software to the customer, and get their feedback.  Based on that feedback, you 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/better suited to the market.  Many if not most software teams are now using variants of this method.

So why am I talking about this in an artist’s blog?

Because, believe it or not, artists 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.  Many Agile ideas apply in art as well, but the particular one I’m thinking of right now is this:

Fail faster!

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 the fiber arts?  It’s all about the dreaded “S” word…sampling.

Sampling is important in a project precisely because it allows you to fail faster.  As an example, consider the color simulation I did in Photoshop:

I didn’t like this design, and won’t be using it in my project.  But notice that, by sampling it via Photoshop, I only took about 10 minutes to discover I didn’t like it.  This mistake 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 simulation/sample, and it saved me a lot of time and grief.

Sampling is a way of reducing risk.  Instead of developing a monolithic project to a set of untried specifications – basically, using the waterfall method and 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.  It’s as simple as that.

I wrote this post for WeaveTech a couple months ago, for someone who was having trouble figuring out what to tackle next, but as I mull over the question of what I want to do next in my quest to become a “serious” artist, it seems apropos to reprint it here.  (More on the “what next” in my next post!)

There’s an interesting concept that comes out of modern software development methodologies – collectively known as iterative development.  Instead of starting with a fully thought-out plan (which almost always changes anyway between the start and finish of a project) and executing to completion, you develop your product in quick iterations, each of which produces a usable product.  This allows you to change plans rapidly as you learn new things about what works and what doesn’t, while still having something finished and usable at any given moment (i.e. it prevents you from wallowing in dithering forever).

The application of this concept to your dilemma seems pretty straightforward.  You can’t plan everything out in advance because you honestly don’t know where you’re going – you don’t have enough information to make a decision.  (That’s what your indecisiveness signifies to me, though I could be wrong.)

So – make a list of the four or five goals that are important to you. Pick one to get started.  Write down a description (“story”) of what that means to you, and pick out one or two items out of that description that you think would be most valuable to tackle first. (It might be something that is so basic that you can’t achieve the goal without it – e.g. “learn to weave” in the goal of “becoming a master weaver” – or it might be the most important thing on the list, or it might be the easiest to knock off the list.  It’s entirely up to you.)

Once you have those one or two items, break it down further into something you can complete – usefully – in a relatively short time period.  (For Agile software development, the suggested timeline is 2-4 weeks, and I think that’s a good place to start.)  “Get the COE in handweaving” is a big task, but the first phase, something achievable within a few weeks, might be “Weave the first two samples in the COE requirements”.  (It should ideally produce some sort of useful end product, so “study tapestry for two weeks” doesn’t really work – you need something more concrete.)

At the end of the first time period, you go back and re-evaluate the goals and priorities.  Maybe you discovered that you weren’t interested in the COE in weaving after all. In that case, you can decide to do something different.  The effort isn’t wasted – you still have the samples, and you still have everything you learned doing the first two samples.  But you consciously re-evaluate every two to four weeks and ask yourself, “What did I get out of the last iteration?  Is it getting me closer to what I want?  If not, what do I need to change to get closer to what I want?  Should I change my goals?”

In this way you can get useful things done while identifying and refining your goals.  It will probably also be much less frustrating than trying to decide everything up front and then be faced with perpetual temptation.

In a related note, I’ve always loved Rainier Maria Rilke’s “Letters to a Young Poet” (Stephen Mitchell translation).  Among other insightful things, he says this:

Always trust yourself and your own feeling, as opposed to argumentation, discussions, or introductions of that sort; if it turns out that you are wrong, then the natural growth of your inner life will eventually guide you to other insights. Allow your judgments their own silent, undisturbed development, which, like all progress, must come from deep within and cannot be forced or hastened.

…have patience with everything unresolved in your heart and try to love the questions themselves as if they were locked rooms or books written in a very foreign language. Don’t search for the answers, which could not be given to you now, because you would not be able to live them. And the point is, to live everything. Live the questions now. Perhaps then, someday far in the future, you will gradually, without even noticing it, live your way into the answer.

There are lots of different ways to interpret those quotes, but what it specifically brings to mind in this context is the importance of experiential, intuitive decisionmaking vs. intellectual analysis when it comes to life goals, and particularly to artistic goals.  I don’t think you’re going to get to a decision about your priorities by making lists, you’ll need to approach it iteratively and experientially in order to get good clarity.  “Living your way into the answer” is something for which the iterative approach works really well, I think.