• (nodebb)

    When they added the extra columns to the application_admins table, it went from just wrong to "dumb like a stone".

  • DayDrinker (unregistered)

    This just hurts -- burn it with fire.

  • (nodebb)

    -- Um, this is evil.

    Yes, that is correct.

    Really, you should to do a separate query against the -- admins table to get the list of admins for each list, instead of this

    What? WTF!

  • MIKE (unregistered)

    And to add insult to injury, the fact the view, retained for backward compatibility, was modified possibly broke it, because for instance some method that made a SELECT * now has extra unexpected columns.

  • Sauron (unregistered)

    Imagine the day they'll need more than 5 admins for an application.

  • Burner (unregistered)

    You're an admin, and you're an admin, everybody is an admin!

  • The Dave G (unregistered)

    Too risky to do it correctly the first time and make the necessary code changes? Or have to modify the table every time you want to add a new admin AND make the SQL changes and and associated code changes. I have a bad feeling the consuming code has been hard coded for Admin1, Admin2, etc.

    This is just plain brain dead.

  • WTFGuy (unregistered)

    But their "methodology" totally followed the Agile YAGNI manifesto. Do not ever think about anything but the smallest subdivision of the immediate task and design solely for the smallest thing that solves the immediate problem.

    Why is this approach popular? It's easy for simple-minded folks to implement (albeit with longer term disastrous results), and it makes the work backlog look as small as possible which makes PHBs very happy. Since technical debt is rarely, if ever, properly accounted for, it doesn't exist. And so cannot be used against the PHBs bonus.

    Regardless of how much hair-tearing & late nights this causes the rank & file techies.

    Why yes, I have been at this a few too many years than is healthy? How could you tell? ;)

  • (nodebb)

    This is why you need NoSQL!

  • Scott (unregistered)

    Won't the max and mix in the query return the same admin if there is only one? I wonder what that does to the applications.

    Regardless, this is the kind of dumb shit I used to deal with every day. Man, I'm glad I'm out of there.

  • (nodebb) in reply to 0x80040005

    This is why you need NoSQL!

    Sure, replace a brain dead SQL schema with an entire brain dead technology.

  • SomeRandomName (unregistered)

    So they said, "The code needs the columns to be admin1 and admin2." Then, rather than fix it, they rewrote the code anyway (and kept on rewriting it) to handle admins 3 to N. I have seen some stupid rationalizations before but that one just might -- might! -- take the cake. And if you'd worked where I did for my last job, you'd understand that it's a pretty big cake.

  • ZZartin (unregistered) in reply to Sauron

    Imagine the day they'll need more than 5 admins for an application.

    Or when they need admins with different levels of permissions.

  • Richard Brantley (unregistered) in reply to WTFGuy

    This is not YAGNI.

    When the second admin was required, they most definitely needed to break the admins to a separate table. They didn’t because the other devs were either lazy, or scared.

    Don’t blame the methodology for people’s inability to apply the principle correctly.

  • tbo (unregistered)

    One admin user on the table, fine. Two admin users, well, we can see what's coming, but okay. But by the time you've changed something twice, it should be clear you need to generalize.

  • Randal L. Schwartz (google)

    I'm gonna start calling things like these "1AF" and "2AF", for "first abnormal form" and "second abnormal form". :)

  • Randal L. Schwartz (google)

    Seriously, I took over a DB project in the middle after the previous sole developer was slipping "one week per week" on his delivery date. Turns out he was tracking a gasoline delivery (gallons of each grade delivered from a supplier to a gas station), and was then informed that "oh, sometimes we pick up gas and mix it, and sometimes we also deliver to multiple stations".

    So he had created for each of the 4 grades of gas four possible pick up locations, and 4 possible delivery gas stations. Yes, the "row" for a single truck trip was now 32 columns just for the gas part of the delivery. And he was getting stuck writing their report generators, since everything now had to account for "if premium grade gas picked up from supplier 2 is null". Yes.

    My solution: I moved everything he did to a different directory (for reference, just in case). Reinstall the DB software. Create a normalized database that has gas components many to one with gas products many to one with supplier many to one with trips. And the same thing on the other side, mapping the gas as blended to the stations of delivery.. And wrote some entry screen code to make sure that all balanced during entry. And then some very simple reports since the data was normalized. I was done in a week from scratch.

  • Randal L. Schwartz (google)

    Seriously, I took over a DB project in the middle after the previous sole developer was slipping "one week per week" on his delivery date. Turns out he was tracking a gasoline delivery (gallons of each grade delivered from a supplier to a gas station), and was then informed that "oh, sometimes we pick up gas and mix it, and sometimes we also deliver to multiple stations".

    So he had created for each of the 4 grades of gas four possible pick up locations, and 4 possible delivery gas stations. Yes, the "row" for a single truck trip was now 32 columns just for the gas part of the delivery. And he was getting stuck writing their report generators, since everything now had to account for "if premium grade gas picked up from supplier 2 is null". Yes.

    My solution: I moved everything he did to a different directory (for reference, just in case). Reinstall the DB software. Create a normalized database that has gas components many to one with gas products many to one with supplier many to one with trips. And the same thing on the other side, mapping the gas as blended to the stations of delivery.. And wrote some entry screen code to make sure that all balanced during entry. And then some very simple reports since the data was normalized. I was done in a week from scratch.

  • WTFGuy (unregistered)

    @ tbo ref

    One admin user on the table, fine. Two admin users, well, we can see what's coming, but okay. But by the time you've changed something twice, it should be clear you need to generalize.

    Always remember one of the deep truths of data: There are only three quantities: zero, one, and many. Anything else is a temporary illusion / delusion.

  • (nodebb)
    Yes, the "row" for a single truck trip was now 32 columns just for the gas part of the delivery.

    Amateur. I once worked on a reservation system that supported 20 people per reservation, each with their own name, address, phone number, etc. If I remember correctly, the table was just over 600 columns.

  • (nodebb)

    Two of something is sometimes tolerable, especially when the join causes a lot of extra data to be sent. More than two, never, unless it's an immutable real-world constraint.

  • NotAThingThatHappens (unregistered) in reply to Randal L. Schwartz
    Comment held for moderation.
  • My Kissasian (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to WTFGuy

    re: But their "methodology" totally followed the Agile YAGNI manifesto...

    (as mentioned in another comment, but worth repeating).... WRONG. YAGNI would apply if there was an implementation of multiple admins with varying roles with varying permissions, with complete audit history created before there was anything more than a single admin needed.

    JIT [just in time] would have said to address the multiple admins as soon as there was the need for multiple admins.

    Also, NOT doing it before then is not "technical debt"... properly used, the term mandates two preconditions:

    1. It is a deliberate decision - not an accident or lack of knowledge or ...
    2. Larger costs in the long run for some time of short term gain is a known consquence of the decision process

    "Idiotic choices" are NOT technical debt - until the choice is reviewed and there is a deliberate decision not to fix/change it knowing it will cost more to do it later.

  • (nodebb)

    The way relationships work in databases appears to be foreign to some people.

    They're geeks, of course many of them are going to be unfamiliar with relationships.

  • German Tiger (unregistered)
    Comment held for moderation.
  • Orbelain (unregistered)
    Comment held for moderation.
  • RLB (unregistered)
    Comment held for moderation.
  • Jay (unregistered)

    There's no reason for the MIN and MAX stuff. There's no reason for more than one JOIN. My guess is legacy data might be an issue, but this doesn't really solve that issue because if admin1 is changed, the MIN function will always give you the old Admin1 instead of the current Admin1.

    What if an Admin changes application roles? In order to make sure they show up, a new Admin record needs to be added and the old admin ID can't be used if it's older than the Admin they are replacing (unless they are replacing Admin1, in which the opposite is true)

    Oh wait! It gets better! They're using varchars. That means the table could be using names instead of IDs. Then the MIN MAX stuff is going to use Alphabetical order to determine which Admins to return.

    Why are all the extra Admins Not Null? If they retroactively made all applications have 5 admins, that's ok, but if they didn't, what are they putting in the extra Admin slots?

Leave a comment on “Foreign to Administration”

Log In or post as a guest

Replying to comment #584239:

« Return to Article