Gregory Consulting is in its 20th year of operation, and at the moment has six employees. I think it's fair to point out you can't stay solvent over that length of time, meeting payroll, paying rent and ISP fees, without some business sense. One of our most important rules is Fail Fast. If you're doing something that might not work, and it's going to fail, it is so much better to fail in the first week than in the sixth month. This leads to all kinds of useful practises like doing the risky bits first, prototyping, making little proof of concept apps or subapps, and the like. Note that we don't do these things because a Methodology said we should. We do them because our gut or some little voice in our head says “are you sure that's going to work?” and then our brain comes up with a way to fail fast. Of course not failing at all is better than failing, and these techniques can also put you in the delightful position of knowing it's going to work, and just having to write it.
Fail Fast and "let's try it" can also save you a ton of time spent arguing about what's the best way to do something. Last week, I was at a early code review of an partly-written ASP.NET 2.0 application where someone had put some DataSet instances into Session even though they were used only on a single page. I wanted them in ViewState, because sessions expire and you have some hoops to jump through to ensure the work won't be lost. One developer on the team said putting things in ViewState made your pages too big. I said that wasn't an issue for the amount of data in this app. After about ten minutes of "what if someone pulls up the whole department for a year?" back and forth we decided to just try it. It took 30 seconds to flip the code between using Session and using ViewState. And guess what? After disabling viewstate on the grid, which was making both versions of the page really slow, there was no measurable difference (even for a year's data) between the two approaches. So it's going to use ViewState to make the coding simpler. But I would have been happy even if the experiment had shown the ViewState approach was infeasible, because we'd have found out before a hundred pages were coded.
Joel Spolsky says pretty much any methodology makes good software in the hands of those who are good enough to develop methodologies, and they pretty much all can fail in the hands of those who just follow the rules and do what the methodology says. Big complex process (and as we grow, our process naturally gets more complex) runs the risk of becoming opaque to those who are asked to follow it. That's why we like to come back to some touchstones that explain why we do what we do. Like Fail Fast.
Failure can be a good thing. If it saves you from following a doomed path for a year, you're glad to have failed early rather than late. If you can learn from something that didn't work, it will have earned its keep. This morning I read a story by Steven Sinofsky (no longer an entry level programmer 
) at Microsoft about the failure of a C++ application framework, essentially the first try at what became MFC. He concludes:
When I think back about the dismal failure of our first library ... and how we regrouped, learned lessons, and put those into play, I realized that without that first failure we never would have developed the success criteria that allowed us to build MFC.
I'm never afraid to fail and I am not ashamed when I do. The only shameful things would be to continue to waste time avoiding the final decision that it is a failure, or not to learn from it.
Kate