It has unquestionably become de rigueur to speak of failing as if it is a goal to be achieved. “Fail early and often” has become a mantra coming from Silicon Valley, where it can be argued that I hail from. And I get it. Really I do.
Frankly, it has a message that librarians, who tend to not want to release a software product until they believe it is absolutely perfect, need to hear. The problem is that we tend to spend months of development time before failing when failure could have been achieved much sooner so you could move on to success. So yeah, I get it.
But this post isn’t about that. It’s about just how difficult it can be to give up. And perhaps more specifically, at just which point one decides to throw in the towel. Because I’ve been there. Multiple times. And I still don’t know exactly in which circumstances you bring the axe down. This is because of at least these issues, some of them deep-seated human traits:
- We really, really, hate to fail. This just isn’t a personal preference, we’ve had it drummed into us from childhood. Dare I begin to list the litany of sports sayings about this? No, of course not. It can be boiled down to this chestnut from Vince Lombardi: “Winners never quit and quitters never win.” Quitters never win. Is that the kind of message you want someone to grow up with if you want them to fail early and often?
- It is really, really difficult to make the call to pull the plug. I recall a specific project where I should have pulled the plug but I didn’t. I couldn’t. I was way too invested in it to have that clarity of vision. I believed. I had written the justification for it, I had fought for it, I had lived it. How could I say I had been wrong? Especially since I wasn’t, at the beginning. But I had become wrong over time.
- How do you really know that you won’t succeed if you give it just X more time/money/effort? How? Adding to the problem identified above is the sincere belief that you will just need a little more of something in order to achieve success. This is not just an idle dream. One project I managed that failed really only needed X more of whatever to be real. But the real problem was that time had marched on, and the solution that I had fought so hard to make real was no longer the solution that we needed. Only in hindsight, and with time, did that become clear. But the enchanting prospect of success with only just a little more resources will remain.
- Not everything can be successful in rapid prototyping and short timeframes. The “fail early and often” proselytizers will have you believe that you should know immediately (or very quickly) whether something will work or not. But the problem is that this is not a universal truth. History proves this. Sometimes the environment, people, or society need to catch up to you. Had Sir Tim Berners-Lee given up on the World Wide Web after a couple years of lukewarm reception, we wouldn’t be where we are today. There are other examples I could name, or you could. The point is that speed is not always what leads to success. Sometimes staying power is.
About Roy Tennant
I can’t help but feel that this piece is a bit pointed in the wake of some of the Access 2013 sessions in which myself and others participated. http://accessconference.ca/schedule/
While I fully agree that adopting a culture of rapid failure “is both difficult to do … and won’t always apply to every situation”, I’m not sure who you’re claiming “act like it does”.
Similarly, I agree that “what we need is to figure out the situations where it is right and those where it isn’t”, but I fail to understand why you believe that “we are some distance away from figuring that out”.
What have you seen that leads to this conclusion? Who does “we” refer to? The library community is surprisingly heterogeneous, and one might propose that the best way to figure out the right situations for using a fail-early/often model is to actually try it sometimes on the plethora of projects that we deal with. Learning when it doesn’t work and sharing that knowledge benefits the community just as well.
Dismissing the entire concept because it’s difficult to implement and generalizing about our naiveté in terms of learning how to apply it are both disappointing, especially coming from someone who many librarians look to for leadership.
MJ, despited what it might seem like to you I was not referring to (and indeed don’t believe I had even been a part of or at least remembered) any specific discussion at Access about this. I actually hear a lot about this right here at OCLC, and my physical proximity to Silicon Valley means I basically breathe it in with virtually every breath. Also, I believe I was quite specific that I was NOT “dismissing the entire concept”. Far from it. It is very useful in many situations, just not all by any means.
Well then, my misunderstanding. I’m sure I’m not the only one who would like to understand more about your impression of some ““fail early and often” proselytizers” advocating this approach as being all-applicable, as well as what you have seen directly to make you think that we are so far from understanding when it is an appropriate model to use. For those of us who don’t live near Silicon Valley, we’d like to know why someone in your position would feel this way.
The title brought to mind–yes, this is mild vanity–a recent piece I wrote on the Taiga Forum blog about giving up on discovery layers because it’s a lost battle. I’m actually less concerned with rapid prototyping and quicker development paths than I am with having the luxury of having the time to worry about such things.
What I mean by that is that in libraries we cling to too many projects/programs/services/models that have clearly outlived their heyday, but we’ll ride those ponies into the ground, rather than gracefully dismounting and letting the poor beasts live out their remaining days in some pasture where they can graze in peace. I want us to give up those things, so that the staff we do have has at least some of their time to engage in creative, forward-looking endeavours.
That said, I don’t see much of a disconnect between these two notions, i.e.- between the desire to fail more quickly and to let go of old stuff that has lost its edge. The same tendency we have to cling to these legacy services (both analogue and digital) applies to the approach we take to doing anything new: kill it with process, drag it on way past any normal life expectancy, etc. It’s a mindset that I’d like to see us shake up a bit. Compared to the pace of change in a place like Silicon Valley, libraries change at the rate of glaciers, and that’s pre-climate change glaciers, to boot. Surely there’s a happy medium in there.