Top 10 Things I hate about SQL Server



  • Found this article on the SQLTeam blog:

    http://weblogs.sqlteam.com/jeffs/archive/0001/01/01/5248.aspx

    And yes, he is being sarcastic. My favorite line:

     <FONT color=#000080>WHERE LTRIM(tblTable.tblTable_colMonthList) LIKE '%JAN%'</FONT>

    <FONT color=#000080>Gotta love those table and column names!!</FONT>



  • Fun read :) But how the F is it possible that people DO NOT understand
    it's a joke? Or were THEY joking and it was ME that did not understand
    THEIR joke??? WTF?!?



  • @impslayer said:

    Fun read :) But how the F is it possible that people DO NOT understand
    it's a joke? Or were THEY joking and it was ME that did not understand
    THEIR joke??? WTF?!?


    I think this top 10 list is really a collection of "error reports" the SQL server team has to process.
    Some, like "Select * from @tablename" or "where col in (@var)" are typical beginner's mistakes, I remember that I've made them too.



  • My absolute favorite item:

    @Jeff Smith said:

    Or sometimes I build some cool dynamic SQL strings, but they don't seem to work and I get:

    You are not allowed to truncate the system table 'master..sysobjects'



  • Hillarious!
    Thank you very much for pointing this out.

    This wouldn't happen to be the same Jeff S that posts here is it?



  • yep, it's me !   Glad you enjoyed it.



  • i didnt enjoy it, except for alex's post, it's just ranting from ppl not, getting it



  • @t-bone said:

    i didnt enjoy it, except for alex's post, it's just ranting from ppl not, getting it


    In addition to that, it is a joke.


  • ♿ (Parody)

    I wish that Weblogs.Asp.Net didn't turn commenting off after a few days, otherwise you guys could see the amount of positive, non-sarcastic feedback I've gotten about my introduction of Front-Ahead Design.  Every now and then, I get an email that pretty much has the tone of this guy (http://www.hairy-spider.com/PermaLink,guid,11adadc9-45b7-4446-a563-b74c4e5b12d2.aspx), thanking me for putting words to something they've lived by.

    I just don't have the heart to explain to them the definition of sarcasm. So yes, Jeff, I feel your pain, just slightly differently :-)



  • @Alex Papadimoulis said:

    I wish that Weblogs.Asp.Net didn't turn commenting off after a few days, otherwise you guys could see the amount of positive, non-sarcastic feedback I've gotten about my introduction of Front-Ahead Design.  Every now and then, I get an email that pretty much has the tone of this guy (http://www.hairy-spider.com/PermaLink,guid,11adadc9-45b7-4446-a563-b74c4e5b12d2.aspx), thanking me for putting words to something they've lived by.

    I just don't have the heart to explain to them the definition of sarcasm. So yes, Jeff, I feel your pain, just slightly differently :-)



    That's because FAD is a caricature of agile methods and/or cowboy programming (we know, for you it's the same).
    But, since agile methods really work for some projects, there is a that even FAD works for some projects.


  • But, since agile methods really work for some projects, there is a chance that even FAD works for some projects.



  • But, erm, the interface [i]is[/i] first, right after defining the spec.

    User first.

    So, in Alex's blog post, I is good and [II - V] are complete crap. Yay.



  • @dhromed said:

    But, erm, the interface [i]is[/i] first, right after defining the spec.

    User first.

    So, in Alex's blog post, I is good and [II - V] are complete crap. Yay.


    II and III can be interpreted as exageraten versions of  the "keep it simple" and "you ain't gonna need it" principles found in agile methods.
    IV is obviously a joke, but interpreted as "Diagrams are not a requirement of the process, just use them as often and as long as they are usefull." it's not far from the stuff we have in agile methods.
    V is also a joke, but interpreted as "don't invest 10x the money to make the system live 20% longer" it makes sense, kind-of.

    Sidenote: About 1,5 years ago, in an Austrian magazine about real estates, the chief editor wrote something along the lines of
    "We do not know the requirements for office buildings in 30 years from now, why build office buildings that last longer than 30 years? They will be knocked down anyways." in the editorial.



  • @Alex Papadimoulis said:

    I wish that Weblogs.Asp.Net didn't turn commenting off after a few days, otherwise you guys could see the amount of positive, non-sarcastic feedback I've gotten about my introduction of Front-Ahead Design.  Every now and then, I get an email that pretty much has the tone of this guy (http://www.hairy-spider.com/PermaLink,guid,11adadc9-45b7-4446-a563-b74c4e5b12d2.aspx), thanking me for putting words to something they've lived by.

    I just don't have the heart to explain to them the definition of sarcasm. So yes, Jeff, I feel your pain, just slightly differently :-)



    That's beautiful Alex!  great post, and definitely a good complement to mine. 

    I get so sick of people saying "doing things right" is not efficient.  I have always been the fastest developer in any group I've ever worked with, and rarely have I just thrown code together to quickly "get it done".  Spending time to think about and design your app before jumping in and writing crap results in things being done much quicker overall and with much cleaner code.  part of that process is being sure that you think of and anticipate and understand the needs of your customer, and develop your model to accomodate future needs. 
    Doing that takes absolutely no more time than just throwing together a bunch of crappy code and diving in head first, and the end result is amazingly different.

    That is the hardest part, I always say: writing code is easy, but understanding the goal and the client and the purpose and workflows in your application is the hardest part.  And, of course, it is often the most widely *ignored* part for many programmers who are just interested in figuring out a way to incorporate AJAX into the new application they are writing!




  • This is my favorite comment from Alex's post:

    >>I couldn't get any of the URLs to work and it looks like there's a lot of people laughing here.



    >>Ummmm ... am I missing something?

    Priceless !



  • @dhromed said:

    @t-bone said:
    i didnt enjoy it, except for alex's post, it's just ranting from ppl not, getting it


    In addition to that, it is a joke.


    not if you read the comments on that page, I freaked out when I saw what people were commenting



  • @t-bone said:

    @dhromed said:
    @t-bone said:
    i didnt enjoy it, except for alex's post, it's just ranting from ppl not, getting it


    In addition to that, it is a joke.


    not if you read the comments on that page, I freaked out when I saw what people were commenting


    huh?  You said you didn't enjoy it, because you thought it was ranting ... then someone told you it was a joke ... and then you reply "no, it's not, read the comments" ??

    You do understand that it's a joke, right?  Did you read the comments?




  • @Jeff S said:


     part of that process is being sure that you think of and anticipate and understand the needs of your customer, and develop your model to accomodate future needs. 


    True. Designing the user interface first is IMO a good way to make sure you understand the needs of the customers, since it is something you can show them early and they, being non-techies, understand a prototype of the UI better and faster than, say, a bunch of UML diagrams.
    That part of FAD is something many of us can aggree upon.
    Writing cheap crap just to "get it done" is a bad strategy; but on the other hand, quite a lot of crap is the result of "not understanding how to do it, but trying to do it right". For that reason, if I could not figure out how to do it right, I would choose the most simple implementation (or copy the strucuture of an existing similar module, to keep it consistent at least).



  • @Jeff S said:

    @t-bone said:
    @dhromed said:
    @t-bone said:
    i didnt enjoy it, except for alex's post, it's just ranting from ppl not, getting it


    In addition to that, it is a joke.


    not if you read the comments on that page, I freaked out when I saw what people were commenting


    huh?  You said you didn't enjoy it, because you thought it was ranting ... then someone told you it was a joke ... and then you reply "no, it's not, read the comments" ??

    You do understand that it's a joke, right?  Did you read the comments?



    Perhaps he was saying that some of the comments weren't jokes and that part was frightening?



  • @tlmii said:

    @Jeff S said:
    @t-bone said:
    @dhromed said:
    @t-bone said:
    i didnt enjoy it, except for alex's post, it's just ranting from ppl not, getting it


    In addition to that, it is a joke.


    not if you read the comments on that page, I freaked out when I saw what people were commenting


    huh?  You said you didn't enjoy it, because you thought it was ranting ... then someone told you it was a joke ... and then you reply "no, it's not, read the comments" ??

    You do understand that it's a joke, right?  Did you read the comments?



    Perhaps he was saying that some of the comments weren't jokes and that part was frightening?


    Yeah, he might be saying that, but it is hard to tell .... he hasn't put down a full sentence yet, only fragments .



  • The ironical thing (full disclosure: I am a DBA) is that RDBMS's and SQL are some of the oldest, best thought out, most mature, and fastest technologies we have. Somehow they are simultaneously the most misunderstood, abused, WTF-ridden technologies.

    I laughed my a$$ off at the "top 10" but also cringe a little because the responses ARE an accurate meteric for the rocket-scientists now working out there in the "real world." Yikes.



  • @maldrich said:

    The ironical thing (full disclosure: I am a DBA) is that RDBMS's and SQL are some of the oldest, best thought out, most mature, and fastest technologies we have. Somehow they are simultaneously the most misunderstood, abused, WTF-ridden technologies.


    fastest? compared to what?



  • @ammoQ said:

    @maldrich said:
    The ironical thing (full disclosure: I am a DBA) is that RDBMS's and SQL are some of the oldest, best thought out, most mature, and fastest technologies we have. Somehow they are simultaneously the most misunderstood, abused, WTF-ridden technologies.


    fastest? compared to what?


    XML?



  • @dhromed said:

    @ammoQ said:
    @maldrich said:
    The ironical thing (full disclosure: I am a DBA) is that RDBMS's and SQL are some of the oldest, best thought out, most mature, and fastest technologies we have. Somehow they are simultaneously the most misunderstood, abused, WTF-ridden technologies.


    fastest? compared to what?


    XML?


    lol Good one!



  • @ammoQ said:

    @Jeff S said:

     part of that process is being sure that you think of and anticipate and understand the needs of your customer, and develop your model to accomodate future needs. 


    True. Designing the user interface first is IMO a good way to make sure you understand the needs of the customers, since it is something you can show them early and they, being non-techies, understand a prototype of the UI better and faster than, say, a bunch of UML diagrams.


    The only problem with this is that it falls afoul of the Iceberg Secret (http://www.joelonsoftware.com/articles/fog0000000356.html).  When you show them a prototype snazzy UI, they will completely fail to understand, at a very fundamental level, why it takes you another two years to get the "rest" of the system working.  So they will conclude that you are slacking off and demote you, fire you, buy a competitor's product instead, or whatever.

    So while there are definitely advantages to mocking up prototype UIs, do not under any circumstances show these to managers, customers, shareholders, or anyone else who has any stake in your progress.  Show them only to disinterested third parties - co-workers, friends, random usability testers, etc.  If none of these substitutes is acceptable, do not make the prototype UI snazzy and polished-looking - make it visually represent the actual state of the back-end development at all times.



  • @stevekj said:



    The only problem with this is that it
    falls afoul of the Iceberg Secret
    (http://www.joelonsoftware.com/articles/fog0000000356.html).  When
    you show them a prototype snazzy UI, they will completely fail to
    understand, at a very fundamental level, why it takes you another two
    years to get the "rest" of the system working.  So they will
    conclude that you are slacking off and demote you, fire you, buy a
    competitor's product instead, or whatever.

    So while there are
    definitely advantages to mocking up prototype UIs, do not under any
    circumstances show these to managers, customers, shareholders, or
    anyone else who has any stake in your progress.  Show them only to
    disinterested third parties - co-workers, friends, random usability
    testers, etc.  If none of these substitutes is acceptable, do not
    make the prototype UI snazzy and polished-looking - make it visually
    represent the actual state of the back-end development at all times.





    Good point. For what it's worth, in most cases I present them
    (allegedly "faked") screenshots of the application, stating "This are
    my ideas how it would look like. This is form x, and if you click this
    button, it will open form y." A clickable prototype is too dangerous,
    even though it would be very little effort to build one once the forms
    are drawn.



  • Just read that article on joelonsoftware... He basically says even
    faked screenshots are bad. Well, maybe I'm just lucky, but my clients
    usually understand that a faked screenshot is not the program.



  • @ammoQ said:

    Just read that article on joelonsoftware... He basically says even
    faked screenshots are bad. Well, maybe I'm just lucky, but my clients
    usually understand that a faked screenshot is not the program.


    You may have been blessed with above-average-savvy clients.  :)  There is a fair chance, also, that although they claim to understand that the screenshot is not the program, internally they may be asking themselves just what's taking so long, since it looks finished already??

    One of the reasons for this confusion may be that software construction is so different from other forms of construction with which most people are familiar.  If you're building a house, or a car, you start with the foundation or base frame, and then the skeleton, then some internal components, wiring, plumbing - and at each stage, you can see all the way through the thing and you can see exactly what's been constructed so far.  You generally don't see contractors put up the siding first, and then work away invisibly for months on the foundation, framing members, plywood, etc.  So people who haven't actually built software themselves may have trouble understanding exactly what's taking so long when they can already see the polished exterior.



  • @stevekj said:

    You generally don't see contractors put up the siding first, and then work away invisibly for months on the foundation, framing members, plywood, etc.  So people who haven't actually built software themselves may have trouble understanding exactly what's taking so long when they can already see the polished exterior.


    That's a good metaphor.

    But I've never had any clients who couldn't understand that the image I'm showing them is just that: a flat image, the design, the layout; and that the construction has yet to take place.

    And if they ask... You tell them. :)


Log in to reply