Mike R left a great comment on the post Fail fast, fail hard, fail safe. Because it got so big, here’s my response:
Mike, you’re right: this isn’t the way I’d build a house. It’s also not the way I’d build a space shuttle. Or an airplane. But it’s the only way I’ll write software, for the customer’s sake.
When you build a house, two things are true:
Planning a house is cheap. Houses are predictable. Architects understand how materials will behave and interact. They know what they can build, and how to build it.
Building a house is expensive. It takes a lot of work and materials to build a house. And if you want to try a second time, you don’t get to reuse bits from the first house; you have to build a new house from (literally) the ground up.
When you build software, the opposite is true:
Planning software is expensive. Software is unpredictable. Software developers often don’t know for sure how their materials will behave and interact. Software technology evolves much more quickly than house technology, so at any moment our experience with current technology is limited.
Building software is cheap. If you have to, you can fail at each step until you succeed, without losing the rest of your progress. If you want to build Twitter integration, but aren’t sure how, you can try things which don’t work without sacrificing your existing, working codebase.
Seems like the software model’s more flexible, doesn’t it. It is. That’s why architects use it too. Architects iterate for months or years on designs and plans build in 3D. A lot of those designs fail, and have to be taken back and tried again. They just wait until those iterations are done before they build the actual house. They can do that cheaply, because the transition from plan to building is a solved problem.
The hidden cost of surety.
Mike, allow me to quote from your comment here, not to pick on you, but to respond to a sentiment that is shared among many opponents of XP:
Instead of “fail fast,” don’t do things that “might be worthless.” Figure out whether they will be or not, before you do anything.
Instead of “fail hard,” figure out whether your model is going to fail and don’t build it at all if it won’t. Determine whether or not an algorithm can or cannot recommend a movie. Don’t “do” anything until you know whether it can or can’t.
Instead of “fail safe,” determine in advance whether failure is likely to occur and do not commence work if so. “Failure is never an option” to the guys who are forking out the dough. Don’t promise anything to anyone until you know you can deliver, and until you know exactly how long it will take.
Absolutely. I would much rather work with someone who knows:
- What will work and what won’t.
- How much everything will cost.
- How long it will take.
But there’s a cost associated with ascertaining each of those pieces of information. It takes time and research. The customer has to pay for all that.
XP makes this claim:
Determining the above facts before beginning development is more expensive than the cost of failures along the way.
If that claim doesn’t hold for your situation, then Waterfall is your best friend. But if it does hold, then XP’s rapid iteration is for you.
Not because developers are lazy. Because it’s cheaper for the customer.
That’s not Agile. That’s bullcrap.
One more thing:
The premise of “Agile” (and “Extreme”) is that you can’t know the results until you try (and fail) to do them, and it is also that the folks who are shelling-out the cash to you are willing to do so indefinitely, even though they still don’t seem to have a house to live in. Trust me: they will start asking you, “HOW do you know?” And you’d better have an answer much better than “Real Soon Now… Trust Me.”
Here’s what I’m hearing. I’m hearing that you got screwed. Or someone you know. Because what you’re describing is not XP at all. But I’ll bet someone told you it was.
This is what’s often called “cowboy coding”. A developer says, “We know what we’re doing, because we’re experienced and Agile. Keep us on retainer for…I don’t know…a few months maybe? And then we’ll probably give you something. Unless it takes longer.”
In XP, we deliver working software at the end of every iteration. At Pivotal, that means every week. You will not go seven days without seeing and approving a working piece of software. It’s not “Real soon now”. It’s “Right now”.
But what about business?
Look, I’ve never run a business myself. But I have written a lot of software in a lot of different ways. And it strikes me that business can be a lot like software. Most of the time, you don’t know how it’s going to behave unless you try. Which means that the cost of planning everything up front is greater than the cost of trying and failing and iterating. Which is why anyone ever invests in a startup. And why the verb “pivot” has so much currency.
My point is just this: All other things being equal, by all means, favor the sure thing over the big risk. But before you do, ask yourself: how much am I paying, before we even get started, just to be sure?