• (cs) in reply to Buell
    Buell:
    Some of you may have missed a very important part of this article. This wasn't just ANY steaming pile. This had field names that were very VERY descriptive, like FIELD23. I'm sure that FIELD23 was the 23rd field in that table and that the field's name adequately described the field's location in that table. However, I am quite sure the suggestion, "recreate the table layout to have meaningful column names," would improve the application to the point where a new coder could at least understand what the database had in it.

    While I'd certainly not want to support the application described, I think I sense some inexperience here.

    For one, I'd certainly not put any confidence in the placement of FIELD23 until I counted out its position myself. I've seen too many databases where the fields were named something like, 'ID, VALUE, FIELD1, FIELD2, FIELD4, FIELD6, FIELD5, FIELD7, ...'

    For another, I'm not all that certain one can come up with a single, consistent name for all the uses to which FIELD23 is put. Given the way the rest of the app was designed, I'm expecting that they have one table that should be multiple tables, and depending on the values of other columns, FIELD23 could be any one of a dozen different things.

    The program should certainly be refactored, as it's virtually guaranteed to be a disaster waiting to happen. But it's probably not going to be as easy as you think it will.

  • (cs) in reply to db
    db:
    However on the other hand the boss is likely to remember the days when there was a major crisis every week and think very highly of the people that are running things without one.

    Until a reorganization changes the boss, or the boss' boss, or something like that. And that's if you're lucky.

  • Buell (unregistered) in reply to tgape
    tgape:
    Buell:
    Some of you may have missed a very important part of this article. This wasn't just ANY steaming pile. This had field names that were very VERY descriptive, like FIELD23. I'm sure that FIELD23 was the 23rd field in that table and that the field's name adequately described the field's location in that table. However, I am quite sure the suggestion, "recreate the table layout to have meaningful column names," would improve the application to the point where a new coder could at least understand what the database had in it.

    While I'd certainly not want to support the application described, I think I sense some inexperience here.

    For one, I'd certainly not put any confidence in the placement of FIELD23 until I counted out its position myself. I've seen too many databases where the fields were named something like, 'ID, VALUE, FIELD1, FIELD2, FIELD4, FIELD6, FIELD5, FIELD7, ...'

    For another, I'm not all that certain one can come up with a single, consistent name for all the uses to which FIELD23 is put. Given the way the rest of the app was designed, I'm expecting that they have one table that should be multiple tables, and depending on the values of other columns, FIELD23 could be any one of a dozen different things.

    The program should certainly be refactored, as it's virtually guaranteed to be a disaster waiting to happen. But it's probably not going to be as easy as you think it will.

    Haha! Sir, you are absolutely correct. I have never actually seen a database that used "FIELD[1-9][0-9]?" as field names. I have seen what you describe next, Fields that have meaningless names because their content is of an inconsistent type. I did not think of this. However, considering each table was uniquely defined for each screen I would certainly hope that there was not enough data to be inconsistent in the use of each field. With views, as I suggested a couple of posts down, this "refactoring" would only have to occur on new or updated modules.

    We could argue the possibilities of how bad the code actually is, but I feel that it would be a trivial pursuit of a destination we will not obtain without consulting the code.

  • Duke of New York (unregistered)

    you know, I hear recaptcha works pretty well...

  • (cs)

    The real WTF is that they didn't shoot him down like the glorious senior experts they are but instead respectfully acknowledged the merit of his idea and gave him an honest reason why they didn't want to implement it.

  • (cs)

    Good Article but not too fine.

    http://www.hilarysweightloss.com

  • hoodaticus (unregistered)

    The database is directly tied to the UI? GENIUS! Why didn't the Direct3D team think about that?

  • hoodaticus (unregistered) in reply to Jon E.

    Which is why you should create graphics for every serious project you do - even for a freaking library. Good, custom graphics, preferably animated and 3-D-looking, shuts up all the management idiots who are ignorantly inclined to wonder aloud to your client whether or not he is getting his money's worth. The reject pile often can be recycled for the 2.0 release.

  • hoodaticus (unregistered) in reply to Neil
    Neil:
    He laid out a 3-part "app revamp" and database redesign plan to improve the system on his first day after working on his first task.

    Seems a bit presumptuous to me, rather than being stuck with older devs who won't change their ways, as the article would like you to believe.

    Agreed that it was a total revamp proposal. I can't agree that it was presumptuous: what was this guy hired to do? Type? It's blatantly obvious that the system of adding a table per new screen type is shit. And when you find shit, you clean it up - unless your boss is a fecalphiliac.

  • Andrew (unregistered)

    Why are there so many WTFs about people who have grand ideas to change something, write a proposal, present it to their boss, just to have it shot down and told "we keep it complicated to keep our cushy jobs"?

    In my job, while not centrally a programming job, I do a fair bit. When I see somethign wrong or something could be done better, I change it. As long as it works the same as before, no one will even know a code change occured. If the system worked exactly as it did before, the code was just cleaner (logically organized, efficient, etc...), do you think anyone would even bother looking at it? So you take a little longer doing a "simple copy and paste" job. Just tell your boss you were familiarizing yourself with the system. They may think you a little slow, but who cares.

  • Duke of New York (unregistered) in reply to Andrew
    Andrew:
    Why are there so many WTFs about people who have grand ideas to change something, write a proposal, present it to their boss, just to have it shot down and told "we keep it complicated to keep our cushy jobs"?
    Because there's a steady supply of narcissistic junior programmers who have no sense of efficiency, and therefore confuse it with maliciousness.

Leave a comment on “I Wish I Worked for PEDANT”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article