When Software Architects attack!



  • Not literally...but one did cause us to lose almost a day of work...

    He was one of those who did software and DB coding...

    And I guess he was trying to move data or something, because he assumed his write to a temp table worked. But it didn't, and so it wiped out a LOT of data we were using in our development environment. It broke all kinds of stuff, because now keys were off, and we had records that wouldn't match...


  • Winner of the 2016 Presidential Election

    @John2 said:

    he assumed his write to a temp table worked.

    :facepunch: :facepalm:



  • Keep in mind this is the same group of people who used to "code review" us, and tell us where OUR code was wrong...


  • Winner of the 2016 Presidential Election

    SELECT * FROM `temp_table` LIMIT 1;: 1s
    Not obliterating the dev table: PriceTimeless



  • Yeah, he didn't put checks in. He just wrote the stored procedure, ran it, and hoped for the best, I guess. Because IIRC what happened is that his code tried to create a temp table, but didn't actually error check, and then truncated (or dropped, I don't recall) the table with the data in it...


  • Winner of the 2016 Presidential Election

    That's exactly the kind of operation you shouldn't do automatically either. Moving ALL THE THINGS is something you should do manually, very, very carefully...



  • Here's another one from the same guy...the guy who's the architect, and is supposed to point these things out at design-time.

    We put together some tables, and used the standard int type as the ID field. Well, our code is heavily reliant on data types matching up. So we write the C# with an int data type, as well, for this field.

    So the architect, without telling us, changes the int field in the DB to a bigint, and chaos ensues. All kinds of stuff breaks.

    So then we lose a day or two "fixing" code that wasn't broken if he would have left things alone.

    Seems they were worried about ID numbers or some such, and were afraid they'd run out. Or something.



  • @John2 said:

    So the architect, without telling us, changes the int field in the DB to a bigint, and chaos ensues.

    1. Where are the validation tests on his changes?
    2. Where are the validation tests in your application code?


  • @sloosecannon said:

    That's exactly the kind of operation you shouldn't do automatically either. Moving ALL THE THINGS is something you should do manually, very, very carefully...

    Considering:

    @John2 said:

    It broke all kinds of stuff, because now keys were off, and we had records that wouldn't match...

    You should also maybe do it when the application isn't actively running on the database.



    1. Don't know. I guess he figures he's an architect...
    2. We have unit tests in place. I think one of the guys on our dev team actually noticed something was broken when he arrived and ran the unit tests after updating his local code from the repository. I'm guessing either the architect didn't do that, or just figured we'd handle it.


  • Oh, this was DEV data, so I don't think he was too concerned. We were, though, as we us Agile and we lost a couple of days "fixing" code that didn't initially need to be fixed.



  • @John2 said:

    We were, though, as we us Agile and we lost a couple of days "fixing" code that didn't initially need to be fixed.

    Can you explain how using(?) "Agile" means you had to fix stuff where if you weren't using(?) "Agile" you wouldn't have had to fix stuff?



  • Oh, we still would have had to fix it, but it was in the middle of our iteration, and we had to stop what we were doing, and almost missed a successful iteration because of it. They frown upon us "missing" iterations where I work. They want us "code complete" by day 7, so we can give the QA team 3 days or so (of a 10 day iteration) to do their jobs correctly.



  • @John2 said:

    We put together some tables, and used the standard int type as the ID field. Well, our code is heavily reliant on data types matching up. So we write the C# with an int data type, as well, for this field.

    TRWTF... you should use Long and BIGINT where you know your table will grow a lot.

    @John2 said:

    So the architect, without telling us, changes the int field in the DB to a bigint, and chaos ensues. All kinds of stuff breaks.

    That's is stupid, but leaves me wondering if there's a bigger WTF down there, where the SQL types get translated to C# types. I mean, it shouldn't break unless you already passed the Integer.MAX value.

    @John2 said:

    and were afraid they'd run out

    This is a real possibility and there are some articles around here about that.

    @John2 said:

    Keep in mind this is the same group of people who used to "code review" us

    They should code review themselves too.



    1. They already had a "convention" in place for most (all?) of their tables for int to be used -- we were basically following convention.

    2. One of the principal developers wrote most of a "framework" to use. This framework somewhat simulates Entity Framework, except that we have to also inherit RegularFrameworkClass or BigFrameworkClass, based on the int (or bigint) declaration. Most of the classes we used inherited RegularFrameworkClass, but after this Architect made the change, we had to go back and change RegularFrameworkClass to BigFrameworkClass.

    I don't know if they're afraid they'd run out. They wanted the ID to maybe start at a specific number, I guess? But still, that 2 billion plus would allow them 6 records per second, for about a decade before they needed to change anything.

    They didn't tell us (or coordinate with us) to make the change. They just did it, and didn't tell us.



  • @Eldelshell said:

    TRWTF... you should use Long and BIGINT where you know your table will grow a lot.

    When I was still a very inexperienced programmer, my first try at a guestbook using PHP and MySQL found me using a TINYINT (a byte by another name...) for the ID field.

    Yeah. Found out very fast why that was a dumb thing to do. In my defense: In those days of yore, I only had money for a whoppin' 50 MB of server space. Including e-mail.



  • @Rhywden said:

    TINYINT

    What an adorable name. Were there ITTYBITTYSTRINGs as well?



  • Yeah. It's called a "bit". :stuck_out_tongue:


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.