Working here... it's priceless.



  • We are working on a new version of our managing software. The first version is the biggest WTF I've ever seen (not only the code; the database is a real messy bunch of hundreds of tables); so the next have to be as close to perfection as possible.

    • First WTF: the boss said to his boss and to the full company "It's easy, it will be done in 60 days". 18 months after, we are releasing the first complete module. On 10. Which are made of a lot of smaller modules. Which are still not designed.
    • WTF n°2: the boss did't want to rewrite the database. "Too complex", he said. "Instead, create temporary tables with the version number in prefix.". Now the development team have to map hundreds of tables made of tens of fields irrelevant to each others PLUS temp tables designed only for testing in Nhibernate, 'cause .Net 4 don't handle Oracle natively.
    • WTF, the third: the boss (still him) said, very seriously, "If we have too much fields in a table, say 50, why not cut it in multiple parts? so we will have 'Table1' with the first 50 fields, 'Table2' with fields from 51 to 100, 'Table3' from 101 to 150...". The idea of the century: fuck off relationnal databases, make mapping harder for developpers with useless joins instead of extracting irrelevants or unused fields in relevant tables with, I don't know, clear names! Yeeeeha! He was pretty sad when everybody laughed at him.
    • Final WTF: wonder who wan't to code with the dev team in his spare time? come on, you'll find... not he's a really bad coder, but development techniques have evolved within 20 years with, let's said, object oriented languages?


    I hesitate between staying here to see if my boss will be fired and buying a rope.

    Bonus WTF: who said "We don't have money to pay you correctly. Actually, you're all bad coders and I'm better than you. And you complain when I want you to add a major untested feature two hours before releasing! For all these reasons I hire contractors which cost four senior developpers." ? luckily, the contractors are pretty good. And they understand our pain.



  • @gobes said:

    WTF, the third: the boss (still him) said, very seriously, "If we have too much fields in a table, say 50, why not cut it in multiple parts? so we will have 'Table1' with the first 50 fields, 'Table2' with fields from 51 to 100, 'Table3' from 101 to 150...".

    In your particular case this may be a WTF, but it's a well-known approach called vertical partitioning. Although it should be based on field size and usage patterns rather than pulling a number out of the air and partitioning into random sets of that size.



  • I totally agree ; if only we had a pattern... here the idea was really to cut tables with more than 50 fields, just to make them more readable in Tortoise...



  • @pjt33 said:

    In your particular case this may be a WTF, but it's a well-known approach called vertical partitioning.

    Yah but I would consider that a last resort optimization. I don't know, maybe you do it all the time, but it makes everything so much more difficult to deal with both conceptually and in code.



  • @pjt33 said:

    @gobes said:
    WTF, the third: the boss (still him) said, very seriously, "If we have too much fields in a table, say 50, why not cut it in multiple parts? so we will have 'Table1' with the first 50 fields, 'Table2' with fields from 51 to 100, 'Table3' from 101 to 150...".
    In your particular case this may be a WTF, but it's a well-known approach called vertical partitioning. Although it should be based on field size and usage patterns rather than pulling a number out of the air and partitioning into random sets of that size.
     

    The next "logical" step is of course to realize that you don't need all these columns when you prefix each record with the column name!

    That, BTW, would be sane in comparison to the DB I worked with. It had records with timestamp, sourceid, and 5 columns, imaginatively called value1 through value5, and there was an extra id which told you what values there would be in each of the value columns. And then of course there were several of these "value group id"s that had the same items, but ever so slightly different.

    Anyway, enough about that. Your boss is a ... boss. You have my sympathy.



  • @TGV said:

    That, BTW, would be sane in comparison to the DB I worked with. It had records with timestamp, sourceid, and 5 columns, imaginatively called value1 through value5, and there was an extra id which told you what values there would be in each of the value columns. And then of course there were several of these "value group id"s that had the same items, but ever so slightly different.

     Ah, the Rich method of database design!  Well, if you take out the "value group IDs", that is.

    "Rich" being his name, of course.  Great boss (he kept the BMFH in line while he was there), poor criminal (embezzlement, fraud, and interstate flight to avoid prosecution were the charges, as I recall), horrid coder (data conversions in Microsoft Access .mde files, data columns "Data1" through "Data75", and God help you if you assume that Data1 for conversion A is the same as Data1 for conversion B).

     



  • @BPFH said:

    data columns "Data1" through "Data75"

     

    That's terrible

    The "Data" part of the column name is superfluous. He could have saved quite a bit of memory by just naming the fields 1-75


Log in to reply