Developer Rant



  • Today I was asking a fellow developer how printers were set up in a certain system.  From personal experience it's usually something mundane like a table with location, printer name, description, and active flag set to Y/N.  However, did this guy do things like this?  Noooo...instead he wanted to write a catch-all solution so any program could find any destination for any kind of distribution type (email, flat file, printer, carrier pigeon, smoke signal, etc).  In the end there are several tables involved each with their own indexes on several ID columns on each.  Extreme overkill to the max! 

    Here's how our conversation went today:

    "Ok, can I just use the columns PRINTER_LOCATION and DEVICE_NAME in tblPrinter_Define_Location_Master and be done?"

    "Yeah, technically you could and have an 'orphaned' record out there, but be sure that you increment the id column MAX+1 on each insert."

    "Isn't there a Sequence on the table?" (this is Oracle, BTW)

    "No, but don't use one since the web screens uses MAX+1 for defining and we aren't touching that part anytime soon"

    Now, one might think "oh, go in and fix the web to use a sequence and be done" but in big corporate land, thanks to bureaucracy, no maintenance updates are allowed that could possibly maybe introduce risk (real or imagined) unless it's broken with no workaround or you can justify to someone that they need to spend cash on such a change.  Sometimes, I miss my cowboy coding past...


  • ♿ (Parody)

    @Mark Bowytz said:

    Now, one might think "oh, go in and fix the web to use a sequence and be done" but in big corporate land, thanks to bureaucracy, no maintenance updates are allowed that could possibly maybe introduce risk (real or imagined) unless it's broken with no workaround or you can justify to someone that they need to spend cash on such a change.  Sometimes, I miss my cowboy coding past...
    You mean in the sensible world.  How many times has that simple little change broken all sorts of stuff.  A hobby project is one thing, but for a business, that costs money.  It may be a WTF, but it sounds like it's a functional WTF.



  • @boomzilla said:

    You mean in the sensible world.  How many times has that simple little change broken all sorts of stuff.
    There is such a thing as a happy medium.  Changing random things because you feel like it is stupid, but so is becoming ossified because you're so risk-averse that you daren't even change the text of a comment in case the compiler turns out to have a really weird bug that causes code to break just because its byte offset in the file has changed.

     Risk should be managed, not blindly avoided.  That means you need process, sure - but that process needs to be more than a big rubber stamp that says "Denied".


  • ♿ (Parody)

    @Iago said:

    Changing random things because you feel like it is stupid, but so is becoming ossified because you're so risk-averse that you daren't even change the text of a comment in case the compiler turns out to have a really weird bug that causes code to break just because its byte offset in the file has changed.
    Yeah, but you're making up a situation that doesn't even come close to what the OP was talking about.  His situation had lots of potential for catastrophe.



  • Saying no to that change isn't about avoiding risk, it's about the time and money to code, test, and move to the production environment a change that while correct, doesn't change the way the program functions in any way.

    Considering the software does function properly right now, and isn't about to break because of that, and that programatically correct internal printer managing software probably doesn't have anything to do with the company's bottom-line, making the change right now doesn't make any sense.

    You make a note of the issue, and slip in a fix the next time you have to make a remotely consequential change to that software.



  • @Iago said:

    ... in case the compiler turns out to have a really weird bug that causes code to break just because its byte offset in the file has changed.

    Such bugs do exist.  There was one on this site I think (either front page or side bar), but I can't find it now.  It was caused by code falling on input buffer boundary and failing to parse properly, thus needing padding with an otherwise useless comment.

    I agree though, not changing anything because there might be a 0.1% risk involved is just stupid.  In case of incorrect design it may be cheaper in the long run to fix the design once the problem is spotted than to let it propagate and require workarounds elsewhere.  The way I'd have done the printer table would be to make the ID column take its value from a sequence by default, thus eliminating the need to do that on the client side.


Log in to reply