Printed 2017/08/18 06:26PM

No Excuse

By Steve Jones, 2007/05/04

I know writing and working on SQL Server is hard. It's a huge project and just managing that is hard. Andy and I argue about this all the time when we find things wrong. My feeling is that once a single person can't keep the entire project organized themselves, it gets out of control and you get inconsistencies. So I sympathize with bugs that get out and I can understand how they do.

I even can get that sometimes you'll get a programmer that takes a short cut and then the worst QA guy, or a guy not paying attention is assigned to test it and doesn't. Or doesn't do it well and then one of us finds the issue. So for the most part I can live with and understand the bugs that arrive in the product. While I wasn't happy with the maintenance plan bugs in SP2, I could understand how they got through.

Andy says that Microsoft has a huge advantage though: they have tons of resources (people and money) to throw at the problem. That's true and you'd expect less mistakes from them, but they also have a much larger scale of places and places the product has to work, so I can understand that they tend to cancel each other out somewhat.

But some things are extremely shoddy programming.
 I saw this entry by Tony Rogerson and this is just plain shoddy programming. It's just piss poor, unacceptable, crappy stuff I expect from less professional programmers. Limiting a server name to 30 characters?

That's just dumb.

I know they probably needed some limit. After all you'd be declaring some array and want to size to at some length, but 30 characters? That's just poor judgement by someone in the real world assuming that everyone uses short server names. Even if they found the longest server name at MS was 20 characters, make it bigger than 30. If you stopped at 99, or even 50, I could understand, but 30 seems too short.

This is another one I think MS should apologize for.

Copyright © 2002-2017 Redgate. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.