The "by design" abuse

Marco Russo (SQLBI) — Thu, 19 Jul 2007 20:34:00 GMT

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!

Microsoft Business Intelligence Conference 2007 website live

Marco Russo (SQLBI) — Sun, 14 Jan 2007 08:41:00 GMT

The Microsoft Business Intelligence Conference 2007 website is now live. The conference is scheduled on May 9-11, 2007, in Seattle, WA. It's not a "traditional" Microsoft technical conference like TechEd and PDC: it's targeted more on project managers, decision makers, IT manager... and, yes, also IT professionals, but this indicates to me that only a part of the conference schedule will be dedicated to the (inside) technical side of Microsoft BI Products.

There is call for presentations dedicated to customer success story (I have a few possible proposals, but I will ask them before) and a section for customer awards nominations.

At this time there are no details on session topics, but only a track page containing only track names.

Strangely to me, Microsoft has (still?) not considered to give visibility to user communities, and I think this is not a good decision. In the last years Microsoft has made big investments in an effort to be more open toward their customers. "User communities" (with this term I mean peer-to-peer activities in general, ranging from blogs, forums, user groups, actions and sites that share the knowledge in general) in the BI market are still a rarity and probably only Microsoft has a minimum number of them.

This is not to say that I would like to be invited, but only that a BI professional does not have a reference for an "event to attend" where he can meet his peers. PDC is too much developer oriented, TechEd is too much general purpose, a SQL Conference is too much backend-oriented (we also need the client side, thus an integration with Office is necessary). The name "Microsoft Business Intelligence Conference" would seem perfect for this. I hope Microsoft will not lose the opportunity to leverage on existing peer networks.

SQLBI - Marco Russo : Microsoft

The "by design" abuse

Microsoft Business Intelligence Conference 2007 website live