Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

SQLAndy

I'm Andy Warren, currently a SQL Server trainer with End to End Training. Over the past few years I've been a developer, DBA, and IT Director. I was one of the original founders of SQLServerCentral.com and helped grow that community from zero to about 300k members before deciding to move on to other ventures.

Failing Fast

I’ll have a longer post next week about my own risk strategy, but I wanted to write this first, both to start getting some ideas working and to see the questions that arise. Failure of any kind isn’t widely regarded as good, and I’m not encouraging anyone to not plan. But especially in business and life there often isn’t a way, or a cost effective way, to find out if something will fail before you do it.

Failing fast isn’t the same as failing to plan. It’s recognizing that no matter how great the plan is, it may not work as expected, and the trick is having some checkpoints where you examine progress and if it’s failing, you fix it equally fast, or you stop spending/kill the project. A different view of this is being willing to try an approach that is unproven, perhaps an alternative to something that already works, the proverbial proof of concept. Part of the rationale for a proof of concept is to make sure it works, and if it doesn’t, end quickly.

For example, suppose you’ve come up with an idea for a new toy for the holiday season. You have to make one to get feedback, and you have to do an engineering work up to make sure it can be made in quantity at a reasonable price (and to help set the final price). The quicker you can get at least a mock up done the quicker you get feedback…and perhaps you fail early, before you invest in the patent and all the rest. So you could call it testing, or validation, or concept analysis, but it’s really a way to frame that it’s ok to fail early and quickly.

It’s not a comfortable thing for most of to acknowledge that we might fail, or even that we don’t have an all encompassing plan. Yet, it happens all the time. Acknowledging risk and finding ways to explore the risk up front may appear to cause more failures, but I think in practice that it leads you to try more things than you would otherwise. It’s mapping the edge cases because you know you can handle the main case.

Pulled a few links on related topics:

Comments

No comments.

Leave a Comment

Please register or log in to leave a comment.