Not exactly what I expected...



  • We work for a large client who has subcontracted various bits of their system to various software companies. My company writes WCF services and database code, which is then consumed by another dev company (I'll call them B) that marries our code with a WPF/Silverlight frontend that the client can actually use.

    In the past there have been some... lapses of communication between all parties, with the end result that B ended up (badly) writing a WCF service that I'm currently having to refactor to fit in with our code. This is about as much fun as eating toothpicks, but what's even more fun is communicating with B's employees when we need some information.

    Case in point: today the B guys emailed some additional classes that need to be included in this service, but neglected to send along any database schema. I emailed the developer responsible and asked him to send the definitions for the requisite tables. I was expecting to get a SQL script, but shortly afterwards I received a reply containing a PDF attachment.

    Hmmm, okay, maybe they renamed the .sql file to ensure it got past our firewall. So I open the PDF.

    It contains a single page of screenshots of the appropriate tables from an ERD tool; not a single "create table" SQL statement in sight, and of course, nothing to give me any insight as to how the tables are linked to each other, or even any other tables. Cue /headdesk moment, because it would have been better and easier FOR BOTH PARTIES if the B developer had simply used SSMS's "right-click table name -> Script Table as -> CREATE To -> New Query Editor Window". It could only have been more perfect if he'd printed out the PDF, put it on a wooden table, photographed it and scanned it in, then sent the result to me.

    Other WTFs perpetrated by B developers include:

    • Running FxCop on their C# code, then marking every piece of code flagged as "ignorable" so that FxCop doesn't warn about said code the next time. Because it obviously makes more sense to do that, than to correct the spelling of "Sesssion".
    • Having C# code that generates stored procedures for them at runtime, so that if a particular sproc is dropped, it doesn't matter - the code just recreates it instead of doing something logical like raising an error. (And of course, if only 1 sproc is dropped, the code will recreate EVERY SINGLE ONE just to be thorough.) This also implies that every time a sproc is called, their code does an "if exists" to determine if the sproc really is there... naturally, it's blindingly fast.
    • Creating an enumeration of month names (January = 1, February = 2, etc.) because we all know only English is spoken on this planet. (Did I mention our client is multinational?)
    • Creating custom Parse methods for every datatype, because the framework-provided ones aren't good enough.
    • TOO MANY OTHERS TO LIST



  • To be fair, sometimes suppressing an FxCop message is perfectly reasonable. But yeah, if you're ignoring every one, you're doing it wrong.



  • @The_Assimilator said:

    It contains a single page of screenshots of the appropriate tables from an ERD tool;
     

    How did you respond? How did he respond?

    Man, complete the narrative, willya.



  •  Send him back an email with a PDF of a scan of a print of a screenshot of your reply being written out in the email's editor!



  • @The_Assimilator said:

    Creating an enumeration of month names (January = 1, February = 2, etc.) because we all know only English is spoken on this planet. (Did I mention our client is multinational?)
    Wait... an enumeration of the english names? Seriously? I've seen an array of month names in other languages in PHP, because PHP is somewhat retarded when it comes to internationalization, but english? In C#? What the hell, how much time does it take to google the proper way to do that?

    PS: And yes, I know how PHP can output month names in other languages, don't bother with the lecture



  • Nothing wrong with an enum.. it'd be very similar to Public Const MONTH_JANUARY As Byte = 1  -  doesn't mean I'm going to output the name of the constant to the user. 



  • @booghost said:

    Nothing wrong with an enum.. it'd be very similar to Public Const MONTH_JANUARY As Byte = 1  -  doesn't mean I'm going to output the name of the constant to the user. 

    Rookie mistake; month names should never be constants.  What happens when Emporer Obama I pulls a Julius Caesar and renames January to "Obamuary"?  This type of dynamic data needs to be stored in XML config files, preferably a few different ones scattered all over the filesystem--you know, for fault-tolerance.  If possible, try to obscure the variable names as much as possible and bury them in deeply-nested, inscrutable XML constructs.  If that sounds like too much work, then head over to apache.org; they have about 80 different open source Java projects to abstract this for you.



  • @morbiuswilters said:

    Rookie mistake; month names should never be constants.  What happens when Emporer Obama I pulls a Julius Caesar and renames January to "Obamuary"?
    Our only hope is that Sarah Palin can steal the plans for his new socialist superweapon and smuggle them away right under the nose of Joe Biden (SPOILER ALERT: HE'S HER DAD) to the hermit exile Ted Stevens. @morbiuswilters said:
    If that sounds like too much work, then head over to apache.org; they have about 80 different open source Java projects to abstract this for you.
      Yeah, but they'll all have their own XML configurations.  And they'll each require Ant, and Maven, and probably seven other Apache projects, too.  That's why I favor opting for a slightly simpler route: create a single XML file that contains every possible valid XML construct.  This is usally quicker and smaller.



  • This thread is giving me major deja-vu. I'm sure morbs has referred to "Obamuary" before. I keep looking at the dates expecting this to be a rezzed thread or something...



  • @dhromed said:

    @The_Assimilator said:

    It contains a single page of screenshots of the appropriate tables from an ERD tool;
     

    How did you respond? How did he respond?

    Man, complete the narrative, willya.

    I wanted to hulk out and send that B developer an email to stop being an idiot, but sadly my project manager was in the room so instead I sent a politely-worded message, very specifically and clearly, for SQL scripts. I was actually impressed when he managed to give me said scripts. (It's not a language barrier thing BTW - the developer speaks English fine - but more a brain barrier problem.)

    @booghost said:

    Nothing wrong with an enum.. it'd be very similar to Public Const MONTH_JANUARY As Byte = 1  -  doesn't mean I'm going to output the name of the constant to the user. 

    Except that B do output the textual enum names on the frontend... I wouldn't have posted that info otherwise.

    Oh, and in another misguided attempt to have Good Coding Standards(tm), every single element of B's code is commented. With an automatic commenting tool. So not only are all the comments useless, many of them are gramatically incorrect since the documentation generator obviously isn't perfect.



  •  When I've had to deal with external clients, vendors, partners, affiliates, etc., with whom I had to implement data-exchange systems, often instead of talking directly with the tech-type at the other place, I've had to channel the communication so it goes from me to a marketing type here to a marketing type there, and finally to the actual tech guy.  Passing through two marketing types tends to garble all messages to the point of incomprehensibility, plus they tend to think that proprietary M$ formats like Word and Excel are reasonable data exchange formats.



  • @dtobias said:

    plus they tend to think that proprietary M$ formats like Word and Excel are reasonable data exchange formats.

    They are.

    If you are doing work for me and gripe about the openness of a document format, I am left to assume 1 of 2 things:

    1. you are 16 and your office is your parents house, so you cant afford "M$" office
    2. you are 22 and your office is a dorm room, so you are retardedly idealistic, and waste time arguing about trivialities rather than get work done



      Either way, I would take my business to a big boy who plays with big boy toys. Software is a tool, and it does what you make it do, which judging form your post is very little


  • @chikinpotpi said:

    @dtobias said:
    plus they tend to think that proprietary M$ formats like Word and Excel are reasonable data exchange formats.

    They are.

    If you are doing work for me and gripe about the openness of a document format, I am left to assume 1 of 2 things:

    1. you are 16 and your office is your parents house, so you cant afford "M$" office
    2. you are 22 and your office is a dorm room, so you are retardedly idealistic, and waste time arguing about trivialities rather than get work done



      Either way, I would take my business to a big boy who plays with big boy toys. Software is a tool, and it does what you make it do, which judging form your post is very little
    I agree entirely and award you 10 points, plus a bonus of 2 points for mocking the use of "M$".



  • @chikinpotpi said:

    @dtobias said:
    plus they tend to think that proprietary M$ formats like Word and Excel are reasonable data exchange formats.

    They are.

    If you are doing work for me and gripe about the openness of a document format, I am left to assume 1 of 2 things:

    1. you are 16 and your office is your parents house, so you cant afford "M$" office
    2. you are 22 and your office is a dorm room, so you are retardedly idealistic, and waste time arguing about trivialities rather than get work done



      Either way, I would take my business to a big boy who plays with big boy toys. Software is a tool, and it does what you make it do, which judging form your post is very little
     

    If you're setting up automated data imports/exports that go through Perl scripts running on Linux machines, plain-text-based formats like CSV are much more suitable for this than some proprietary binary data format.  Not to mention how Excel does idiotic things like stripping leading zeroes from zip codes, or worse, putting credit card and telephone numbers into exponential format, making me feel like committing some highly violent crime on whoever was responsible for perpetrating it.

    (And I'm 46, so I'm a curmudgeonly old man who remembers when computers had only a few kilobytes of memory, and stored data on 5.25" floppies if not on cassettes, so bloatware was not an option.)

     



  • @chikinpotpi said:

    Either way, I would take my business to a big boy who plays with big boy toys. Software is a tool, and it does what you make it do, which judging form your post is very little
    I don't care if you're using OpenOffice or MS Office, if you're embedding screenshots of webpages inside word processor documents, I'm going to insult you.



  • @dtobias said:

    (And I'm 46, so I'm a curmudgeonly old man who remembers when computers had only a few kilobytes of memory, and stored data on 5.25" floppies if not on cassettes, so bloatware was not an option.)

    Oh, so you're obsolete.  That explains a lot.



  • @dtobias said:

    If you're setting up automated data imports/exports that go through Perl scripts running on Linux machines, plain-text-based formats like CSV are much more suitable for this than some proprietary binary data format.  Not to mention how Excel does idiotic things like stripping leading zeroes from zip codes, or worse, putting credit card and telephone numbers into exponential format, making me feel like committing some highly violent crime on whoever was responsible for perpetrating it.
    Now I'm not saying I'd personally opt for using Excel for data exchange, but my complaints would never include "proprietary" or "M$".  They'd be more likely to include things like "needlessly cumbersome" or "overkill".  Or maybe, if I were really drunk, things like "OMG!! teh JSON" or "XMK" (which is how I type "XML" when drunk).

    @dtobias said:

    (And I'm 46, so I'm a curmudgeonly old man who remembers when computers had only a few kilobytes of memory, and stored data on 5.25" floppies if not on cassettes, so bloatware was not an option.)
    Who gives a shit?  That's like complaining that you're 130 years old and you remember a time where people walked everyone, not used one of these damned horseless carriage contraptions.  Being old doesn't make you wise, or insightful, or right; it just makes you old.  Get with the times or get thee gone.



  • @bstorer said:

    @dtobias said:

    If you're setting up automated data imports/exports that go through Perl scripts running on Linux machines, plain-text-based formats like CSV are much more suitable for this than some proprietary binary data format.  Not to mention how Excel does idiotic things like stripping leading zeroes from zip codes, or worse, putting credit card and telephone numbers into exponential format, making me feel like committing some highly violent crime on whoever was responsible for perpetrating it.
    Now I'm not saying I'd personally opt for using Excel for data exchange, but my complaints would never include "proprietary" or "M$".  They'd be more likely to include things like "needlessly cumbersome" or "overkill".  Or maybe, if I were really drunk, things like "OMG!! teh JSON" or "XMK" (which is how I type "XML" when drunk).

    @dtobias said:

    (And I'm 46, so I'm a curmudgeonly old man who remembers when computers had only a few kilobytes of memory, and stored data on 5.25" floppies if not on cassettes, so bloatware was not an option.)
    Who gives a shit?  That's like complaining that you're 130 years old and you remember a time where people walked everyone, not used one of these damned horseless carriage contraptions.  Being old doesn't make you wise, or insightful, or right; it just makes you old.  Get with the times or get thee gone.

    IMHO, the recipient of a data transfer file should be the one to determine the format/type of said file.  Although this did lead me to have to create a tilde + tab delimited file, with "s as string indicators and # as date indicators.

    On the plus side I just finished a project duplicating the functionality of SSRS in ASP.NET, with no reporting server available.  using vb.net.  yay.



  • @Medezark said:

    IMHO, the recipient of a data transfer file should be the one to determine the format/type of said file.  Although this did lead me to have to create a tilde + tab delimited file, with "s as string indicators and # as date indicators.

    And I've just finished my favourite annual task, compiling data from 2004 onwards and storing it firstly as two tables (asset and revenue) in our Oracle database for our own use, and secondly as 76 Access databases, one for each month of the data extract, each containing a single table with asset data and that month's revenue data joined together. Because that's the format the recipient wants.

    At least this year I finally got around to scripting the Access part so it creates the monthly tables and packages them into their own databases automatically. I would have done it earlier, but I really didn't want to get into Access VBA. Which, surprisingly, turned out to be even [i]worse[/i] than I had dreaded. At least when you're working with VBA in Excel you can tell it was designed by someone who thought sanity might possibly be a good idea, and therefore didn't rule it out.

    And yet, I agree with you. The recipient should specify the format they want, and the sender should deliver that format unless there are significant obstacles to doing so, in which case you can negotiate. Of course, in reality it doesn't quite work like that. I was particularly annoyed by a data cleansing service we used last year; we sent them a sample data file, they sent us a sample cleansed file in pipe-delimited format, I built the interface back to our systems to accept that format. Then, when we actually sent the real files, with each extract columns would appear and disappear, and the delimiter changed from pipe to comma after about the second file. In the end I built a converter mapping to shove data back into the original format, and just modified that each time according to the structure of the latest file they'd sent.

    Of course, the data [i]we[/i] sent [i]them[/i] had to be in a consistent format each time... (and was, naturally).



  • @bstorer said:

    "XMK" (which is how I type "XML" when drunk)
     

    @bstorer said:

    Who gives a shit?  Being old doesn't make you wise, or insightful, or right; it just makes you old.  Get with the times or get thee gone.
     

    You're a mean drunk! :(


Log in to reply