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...
-
-
Keep in mind this is the same group of people who used to "code review" us, and tell us where OUR code was wrong...
-
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...
-
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.
-
So the architect, without telling us, changes the int field in the DB to a bigint, and chaos ensues.
- Where are the validation tests on his changes?
- Where are the validation tests in your application code?
-
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:
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.
-
- Don't know. I guess he figures he's an architect...
- 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.
-
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.
-
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.
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.
and were afraid they'd run out
This is a real possibility and there are some articles around here about that.
Keep in mind this is the same group of people who used to "code review" us
They should code review themselves too.
-
-
They already had a "convention" in place for most (all?) of their tables for int to be used -- we were basically following convention.
-
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.
-
-
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.
-
-
Yeah. It's called a "bit".
