Is Failure an Option?

Kalen explores whether a version of SQL Server can be considered a failure if its missing features that were supposed to be in it.

Kalen Delaney

September 30, 2010

3 Min Read
ITPro Today logo in a gray background | ITPro Today

My friend Buck Woody posted an interesting link a few days ago that pointed me to Microsoft SQL Server engineer Dan Jones’ blog post “What Does Failure Mean to You?” on the topic of failure that really got me thinking. Now I know people toss the word “failure” around very casually, even using it to refer to other people (e.g., “He is a real failure”). I think it’s one thing to say that an attempt to achieve a certain outcome failed, but to say that a person, and by extension their entire life, is a failure, is unwarranted. All of the dictionary definitions I checked refer to failure as pertaining to a specific act. When applied to a person, the definition mentions the non-success of a particular endeavor by that person. To say that one act or even a succession of acts didn’t meet their anticipated goal doesn’t mean the person is a failure.

But this column isn’t talking about people; it’s talking about software products. However, I think there’s some overlap in the meaning of failure. If a product doesn’t do everything the designers intended, is the entire product a failure? I don’t know much about the products Dan mentions in his blog post, but I’ve seen plenty of other features that were proposed and attempted and just didn’t make it into the final product.

The earliest such attempted and then dropped feature that I remember is the introduction of user-defined functions for SQL Server 6.5. Someone even wrote a book that included a discussion of that feature, which ended up being dropped from that version and didn’t show up again until SQL Server 2000.   More recently, early SQL Server 2005 product enhancement lists included the ability to escalate locks to the partition level, and a famous T-SQL expert included a discussion of this capability in a magazine article, but then the feature didn’t show up until SQL Server 2008. SQL Server 2005 originally was planned to include two types of partitioning functions: Range functions and Hash functions. A colleague of mine wrote a white paper on partitioning that included a discussion of hash partitioning, which then didn’t make it into the final product and still hasn’t made an appearance. Similarly, row-level security appeared in some of the early builds of SQL Server 2005, but the feature was dropped and hasn’t reappeared.

So if Microsoft attempts to include a new feature in an upcoming version of SQL Server, and doesn’t succeed in getting the feature completely working before the SQL Server version is released, is that version of SQL Server a failure? Perhaps, if the entire product or project is so far away from the hoped-for behavior that it can’t even be released, we could call the effort a failure, but then the next question is, “Is that always a bad thing?” Buck posted a comment at the bottom of Dan’s blog post implying that failure (I assume in the meaning of “not attaining your specific goal”) isn’t a bad thing at all. He said "If you want to double your success rate, quadruple your failures." It’s only by trying that we can know what works and what doesn’t. And if some of those attempts don’t succeed, we can still learn from them. If we can learn something, it doesn’t seem to me that we failed.

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like