The “by design” abuse

In the last months, I got the infamous “it’s by design” answer for many bugs/issues/irrational behaviors I posted to Microsoft. For most of them I used the Connect web site, in a couple of cases I opened a formal incident to Microsoft support.

There are a lot of story (in and outside Microsoft) about the “it’s by design” excuse and most of them are myths and urban legends. Unfortunately, today I received a notification about a bug closure with the “by design” comment that has the consequence to invalidate Microsoft documentation (ok, a small part of…).

The bug is related to SQL Server. One customer wrote me about a strange issue of the ODBC international date constant syntax {d ‘yyyy-mm-dd’}. I never used that, since I prefer the yyyymmdd syntax, but Microsoft effectively suggests using this in the “Writing International Transact-SQL Statements” of SQL Server 2005 Books Online.

As a consultant, I was a little bit shamed because I never used it and I wasn’t aware of the issues raised by changing the language settings (you know, this syntax should be used just because it’s language neutral…). I double checked the whole thing (I always assume it’s my fault before suspecting it’s a product bug…) and then I posted this bug on the Connect web site. For the lazy of you, this is the repro code.

1:  USE tempdb
2:  GO
3:  IF NOT EXISTS (SELECT * FROM sysobjects where name = 'ProblemDate') BEGIN CREATE TABLE [dbo].[ProblemDate](
4:  [DateA] [datetime] NOT NULL ,
5:  [DateB] [datetime] NOT NULL
6:  )
7:  END
8:  GO
9:  IF NOT EXISTS (SELECT * FROM ProblemDate) BEGIN INSERT INTO [ProblemDate] ([DateA],[DateB])
10:  VALUES ({ d '2004-09-15'} ,{ d '2004-03-30'}) END 
11:  GO
12:  SET language english
13:  go
14:  -- The select run correctly
15:  SELECT CASE WHEN ProblemDate.DateA > {d '2006-11-21'} THEN 'y' ELSE 'x' END
16:  FROM ProblemDate
17:  WHERE ProblemDate.DateB={d '2004-03-30'} 
18:  GO
19:  SET language italian
20:  GO

21:

-- The same select, got an error
22:  SELECT CASE WHEN ProblemDate.DateA > {d '2006-11-21'} THEN 'y' ELSE 'x' END
23:  FROM ProblemDate
24:  WHERE ProblemDate.DateB={d '2004-03-30'} 
25:  GO

If you were able to say that line 22 will generate a date conversion error before running the code, I’d be ready to offer you a pizza everywhere you are in the world.

Now, it seems that I need to prepare a delivery of pizzas to Redmond, since the bug has been closed as “By Design”. Unfortunately, there are no comments to explain such a decision.

I can make several hypotheses:

• The bug has been fixed in a future release and someone pressed the wrong button closing the bug. That’s the optimistic one.
• The bug has been considered not a bug because I need to pay some pizzas to someone.
  • In that case, I will claim the pizzas from the documentation team, which has misguided those few people that RTFM :-)
• The bug has been closed by someone that read one comment to the bug that pointed out a similar issue on the ‘yyyy-mm-dd’ syntax – but it is not a good explanation of the behavior that differs from documentation of the product.

I don’t know. However, the issue I described is not the real problem; it’s just an example to illustrate what happens on the Connect web site. In this case, the answer “by design” has been posted 3 month after the bug submission. Sometime I haven’t seen an answer for many more months. However, it really depends on the team, there are other guys who typically answer in a few days (or some week in the worse case).

I really don’t like writing this kind of posts, but I know that many people in Microsoft monitor blogs like mine and this is a message in a bottle for them. Guys, the whole Connect site isn’t very useful if you will continue to answer with “by design” / “we don’t have resource now” / “it’s not on our plan for the next release (!)”. The last one is my nightmare, because it means that this necessary feature/bug/whatever will be implemented/corrected in a production code that won’t be released until 2011 (assuming that the 3 years gap between SQL Server releases will be maintained).

Posting on the Connect site has a time cost. To me (writing) and to Microsoft (reading and -sometime- answering). I typically post on Connect only after a search in newsgroups and web sites, only when I’m able to describe a repro of the issue. Until today, I submitted 44 comments (bugs and suggestions) for SQL Server 2005 – I’m not the first, but considering an average of 30 minute per post (and I’m not calculating the time to discover the bug of to recognize the need for a feature/change) it means 22 hours of work. Most of my posts are still active. Many don’t have an answer, but I know that Katmai should have improvements covering some of my suggestions. A better update of these submissions would be appreciated…

I think that the Connect web site is a great resource, but it’s not comparable to the kind of support that is offered by some ISV (I use other third-party tools related to SQL Server and .NET programming and they are years-light more responsive). I know, the small size of a company might help in being very efficient in customer support, but I can’t believe that a company like Microsoft is not able to improve the Connect efficiency. In the last 7 days there were 48 new bugs and 31 new suggestions for the whole SQL Server platform (which includes SSIS, SSAS, SSRS, SSNS, SSBS). Are these numbers big? I don’t know. I would say “no, they are not so big for a company like Microsoft”.

Finally… I know, probably there are other priorities. But, in this case, please don’t abuse the “by design” way to fix your bugs.

UPDATE – This bug has been fixed in SQL Server 2008!