• Joel (unregistered)

    Sounds like an old legacy app at our company that uses dBase files.  When the thing you want to search for has no index, it's time to iterate record by record (as SQL isn't available).

  • Joel (unregistered) in reply to Joel

    ...to clarify since that sounds weird, the API used for accessing the xBase files is procedural calls, no SQL.  If it was FoxPro, ODBC, or something, yes SQL would be available.  I wasn't saying you can't use SQL on xBase tables.

  • DigitalLogic (cs)
    Alex Papadimoulis:
    the boss went off on him, criticizing him for coming in at an unauthorized time, making an unauthorized software change, and for compromising the integrity of the warehouse system. Ah well, so is the life of a contractor


    Sounds like its time to find a new contract.
  • Reed (unregistered)
    Alex Papadimoulis:

    Not quite: the boss went off on him, criticizing him for coming in at an unauthorized time, making an unauthorized software change, and for compromising the integrity of the warehouse system. Ah well, so is the life of a contractor

     

    This is the point where you frankly just say "go fuck yourself".
     
     

  • ResidentialEvil (cs)
    Alex Papadimoulis:

    Later that morning, Ivan arrived back at work feeling happy and refreshed. A few people thanked him again and his manager (the other nephew) asked to speak with him immediately. Ivan figured it'd be an official thank-you-for-saving-the-day thing. Not quite: the boss went off on him, criticizing him for coming in at an unauthorized time, making an unauthorized software change, and for compromising the integrity of the warehouse system. Ah well, so is the life of a contractor

     Translation: "Don't EVER make me look bad again by going in and fixing code only a moron like myself would write! My appearance as a great developer is much more important than actually getting things accomplished!"

     Sadly, I've had a few encounters like this; fix a problem that was holding up a lot of work, and the problem being someone higher than me wrote crappy code, only to get scolded for "not consulting with me" or "possibly screwing something up". And of course pointing out it was already really screwed up only made them more angry.

  • Sgt. Zim (cs)
    Alex Papadimoulis:

    Set rsStock = objConn.Execute("SELECT * FROM [Inventory]")
    While Not rsStock.EOF
      If rsStock("ItemId") = intItemId Then
        Call SendItemToTransmitter(rsStock)
      End If
      rsStock.MoveNext
    Wend

    And if I'm reading this correctly, after pulling down millions of rows, and iterating through them, finding the target on, say the 12,384th pass through the loop, doing whatever SendItemToTransmitter does ... It keeps going the rest of the way through the millions of rows.  Or was that just a feature of the anonymo ... anonymiz .... the process of making it anonymous? 

     

    [Note from Alex: Good obvservation. The code is more of a representation/simplification of what it would have looked liked (Ivan didn't save the original) -- but perhaps that's why the nephew didn't notice the bug? He looked for Item 0000001, while the screw is Item 9999901?]

  • Raiko (unregistered)

    Ouch. I hope that was more of a braindead moment than something he would do normally  

  • Griz (unregistered) in reply to DigitalLogic

    DigitalLogic:
    Alex Papadimoulis:
    the boss went off on him, criticizing him for coming in at an unauthorized time, making an unauthorized software change, and for compromising the integrity of the warehouse system. Ah well, so is the life of a contractor


    Sounds like its time to find a new contract.

    Nah, just charge the 1D-10-T tax.

  • KattMan (cs) in reply to Raiko

    Anonymous:
    Ouch. I hope that was more of a braindead moment than something he would do normally  

    In my experiance in situations like this, yes it is something he would do normally.  The problem then becomes caused by the contractor for working unauthorized hours.  The time the contractor started and time the problem occured is not released to the higher ups so this fallacy does not become apparent.  It is also stated that the contractor was lucky to get the system back on line.

    Remember the first rule of contracting, you are the disposible one.

  • Rick (cs) in reply to Reed
    Anonymous:
    Alex Papadimoulis:

    Not quite: the boss went off on him, criticizing him for coming in at an unauthorized time, making an unauthorized software change, and for compromising the integrity of the warehouse system. Ah well, so is the life of a contractor

     

    This is the point where you frankly just say "go fuck yourself".
     
     

    That is the short answer, but to be a little more verbose...

    This programmer has proved himself to be a liability to his boss. The boss who knowingly hires and retains people who know more than themselves are few and far between. It is time to move on.
     

  • facetious (unregistered) in reply to ResidentialEvil
    ResidentialEvil:

     Translation: "Don't EVER make me look bad again by going in and fixing code only a moron like myself would write! My appearance as a great developer is much more important than actually getting things accomplished!"

    Nah, it wasn't him that wrote the code.. It was the other cousin. Remember ... two cousins.. Yeah.

  • KattMan (cs) in reply to ResidentialEvil
    ResidentialEvil:
    Alex Papadimoulis:

    Later that morning, Ivan arrived back at work feeling happy and refreshed. A few people thanked him again and his manager (the other nephew) asked to speak with him immediately. Ivan figured it'd be an official thank-you-for-saving-the-day thing. Not quite: the boss went off on him, criticizing him for coming in at an unauthorized time, making an unauthorized software change, and for compromising the integrity of the warehouse system. Ah well, so is the life of a contractor

     Translation: "Don't EVER make me look bad again by going in and fixing code only a moron like myself would write! My appearance as a great developer is much more important than actually getting things accomplished!"

     Sadly, I've had a few encounters like this; fix a problem that was holding up a lot of work, and the problem being someone higher than me wrote crappy code, only to get scolded for "not consulting with me" or "possibly screwing something up". And of course pointing out it was already really screwed up only made them more angry.

    My usual response to this: Fine I'll go roll back the change.  They immediatly stutter.  Of course 5 seconds later I quit, but never have they rolled back the change.

  • IQpierce (unregistered) in reply to Rick

    This might be my favorite WTF ever.

     

    Aside from this website, which is more and more becoming a WTF. Why the crap don't you use some standard blog technology instead of this weird hacked-up forum with captchas and ads shoehorned in?

  • Dave (not that one) (unregistered)

    So the title is misleading. The screw was not missing, just delayed. Ivan was totally screwed when he got in the next morning.

     

  • UpNDown (cs) in reply to KattMan

    That's when you tell them that you included code that checked for today's date.  So the same problem could occur again tomorrow morning.  No problem then, the system will revert to its intended operation at midnight.

  • initech (unregistered) in reply to IQpierce
    IQpierce:

    This might be my favorite WTF ever.

     

    Aside from this website, which is more and more becoming a WTF. Why the crap don't you use some standard blog technology instead of this weird hacked-up forum with captchas and ads shoehorned in?

    What better way to demonstrate WTF in action than to have your site loaded with WTFery? 

  • themagni (cs) in reply to ResidentialEvil
    ResidentialEvil:
    Alex Papadimoulis:

    Later that morning, Ivan arrived back at work feeling happy and refreshed. A few people thanked him again and his manager (the other nephew) asked to speak with him immediately. Ivan figured it'd be an official thank-you-for-saving-the-day thing. Not quite: the boss went off on him, criticizing him for coming in at an unauthorized time, making an unauthorized software change, and for compromising the integrity of the warehouse system. Ah well, so is the life of a contractor

     Translation: "Don't EVER make me look bad again by going in and fixing code only a moron like myself would write! My appearance as a great developer is much more important than actually getting things accomplished!"

     Sadly, I've had a few encounters like this; fix a problem that was holding up a lot of work, and the problem being someone higher than me wrote crappy code, only to get scolded for "not consulting with me" or "possibly screwing something up". And of course pointing out it was already really screwed up only made them more angry.

    Yeah, welcome to my world. 

    It's now to the point where the project manager won't reply to my emails and only speaks in Mandarin.

    I get paid either way.
     

  • not you (unregistered) in reply to Sgt. Zim
    Sgt. Zim:
    Alex Papadimoulis:

    Set rsStock = objConn.Execute("SELECT * FROM [Inventory]")
    While Not rsStock.EOF
      If rsStock("ItemId") = intItemId Then
        Call SendItemToTransmitter(rsStock)
      End If
      rsStock.MoveNext
    Wend

    And if I'm reading this correctly, after pulling down millions of rows, and iterating through them, finding the target on, say the 12,384th pass through the loop, doing whatever SendItemToTransmitter does ... It keeps going the rest of the way through the millions of rows.  Or was that just a feature of the anonymo ... anonymiz .... the process of making it anonymous? 

     

    [Note from Alex: Good obvservation. The code is more of a representation/simplification of what it would have looked liked (Ivan didn't save the original) -- but perhaps that's why the nephew didn't notice the bug? He looked for Item 0000001, while the screw is Item 9999901?]

    The WTF goes deeper than that, my friend. After looping through the recordset and finding the record with the correct item ID, THE ENTIRE RECORDSET is passed into the function. No global variable is set and no other parameter is passed to let that function know which record to use. Presumably, SendItemToTransmitter loops through the entire recordset AGAIN.

    WTF indeed.

  • marvin_rabbit (cs)
    Alex Papadimoulis:

    ... none of the full-timers are responding!

    Translation: Nephew Daryl and the other nephew Daryl didn't want to get out of bed. 

  • webzter (cs)

    I actually almost clicked the 'Report Abuse' link on this post... because, obviously, Ivan was abused.

    I'd apologize to the boss, roll back the fix, and walk out.

  • marvin_rabbit (cs) in reply to not you
    Anonymous:
    Sgt. Zim:
    Alex Papadimoulis:

    Set rsStock = objConn.Execute("SELECT * FROM [Inventory]")
    While Not rsStock.EOF
      If rsStock("ItemId") = intItemId Then
        Call SendItemToTransmitter(rsStock)
      End If
      rsStock.MoveNext
    Wend

    And if I'm reading this correctly, after pulling down millions of rows, and iterating through them, finding the target on, say the 12,384th pass through the loop, doing whatever SendItemToTransmitter does ... It keeps going the rest of the way through the millions of rows.  Or was that just a feature of the anonymo ... anonymiz .... the process of making it anonymous? 

     

    [Note from Alex: Good obvservation. The code is more of a representation/simplification of what it would have looked liked (Ivan didn't save the original) -- but perhaps that's why the nephew didn't notice the bug? He looked for Item 0000001, while the screw is Item 9999901?]

    The WTF goes deeper than that, my friend. After looping through the recordset and finding the record with the correct item ID, THE ENTIRE RECORDSET is passed into the function. No global variable is set and no other parameter is passed to let that function know which record to use. Presumably, SendItemToTransmitter loops through the entire recordset AGAIN.

    WTF indeed.

    Given the rest of the code, my guess is that "Call SendItemToTransmitter(rsStock)" throws an exception when it works!  That way they got out of the loop.

  • Jeff S (cs) in reply to not you
    Anonymous:
    Sgt. Zim:
    Alex Papadimoulis:

    Set rsStock = objConn.Execute("SELECT * FROM [Inventory]")
    While Not rsStock.EOF
      If rsStock("ItemId") = intItemId Then
        Call SendItemToTransmitter(rsStock)
      End If
      rsStock.MoveNext
    Wend

    And if I'm reading this correctly, after pulling down millions of rows, and iterating through them, finding the target on, say the 12,384th pass through the loop, doing whatever SendItemToTransmitter does ... It keeps going the rest of the way through the millions of rows.  Or was that just a feature of the anonymo ... anonymiz .... the process of making it anonymous? 

     

    [Note from Alex: Good obvservation. The code is more of a representation/simplification of what it would have looked liked (Ivan didn't save the original) -- but perhaps that's why the nephew didn't notice the bug? He looked for Item 0000001, while the screw is Item 9999901?]

    The WTF goes deeper than that, my friend. After looping through the recordset and finding the record with the correct item ID, THE ENTIRE RECORDSET is passed into the function. No global variable is set and no other parameter is passed to let that function know which record to use. Presumably, SendItemToTransmitter loops through the entire recordset AGAIN.

    WTF indeed.

    Aparently, you are not familiar with passing by reference, are you?  the entire recordset is not sent anywhere, just a pointer.  And a recordset has a "currentRecord" concept, so the current record is available to the function.  Passing a recordset object to a function is very, very common and much preferable to using global variables, which is generally considered poor programming style.

    Not understanding basic concepts like this is often how many WTF's are born ... 

    (edited to fix some typos) 

  • shadowman (cs) in reply to facetious
    Anonymous:
    ResidentialEvil:

     Translation: "Don't EVER make me look bad again by going in and fixing code only a moron like myself would write! My appearance as a great developer is much more important than actually getting things accomplished!"

    Nah, it wasn't him that wrote the code.. It was the other cousin. Remember ... two cousins.. Yeah.

    Or they may have even been brothers.  We only know that they were both nephews of the CTO.
     

  • foonly (unregistered) in reply to DigitalLogic

    DigitalLogic:
    Alex Papadimoulis:
    the boss went off on him, criticizing him for coming in at an unauthorized time, making an unauthorized software change, and for compromising the integrity of the warehouse system. Ah well, so is the life of a contractor


    Sounds like its time to find a new contract.

     Nope.  Anyone who has done contracting saw this coming.  The correct reponse is to look contrite, apologize, and add the time spent getting criticized to your bill.
     

  • John Bigboote (cs) in reply to Jeff S
    Jeff S:

    Aparently, you are not familiar with passing by reference, are you?  the entire recordset is not sent anywhere, just a pointer.  And a recordset has a "currentRecord" concept, so the current record is available to the function.  Passing a recordset object to a function is very, very common and much preferable to using global variables, which is generally considered poor programming style.

    Not understanding basic concepts like this is often how many WTF's are born ... 

    (edited to fix some typos) 

     

    Nail, meet head. This is the LEAST wtf-ish aspect of the post. 

  • mrsticks1982 (cs) in reply to Jeff S
    Jeff S:
    Anonymous:
    Sgt. Zim:
    Alex Papadimoulis:

    Set rsStock = objConn.Execute("SELECT * FROM [Inventory]")
    While Not rsStock.EOF
      If rsStock("ItemId") = intItemId Then
        Call SendItemToTransmitter(rsStock)
      End If
      rsStock.MoveNext
    Wend

    And if I'm reading this correctly, after pulling down millions of rows, and iterating through them, finding the target on, say the 12,384th pass through the loop, doing whatever SendItemToTransmitter does ... It keeps going the rest of the way through the millions of rows.  Or was that just a feature of the anonymo ... anonymiz .... the process of making it anonymous? 

     

    [Note from Alex: Good obvservation. The code is more of a representation/simplification of what it would have looked liked (Ivan didn't save the original) -- but perhaps that's why the nephew didn't notice the bug? He looked for Item 0000001, while the screw is Item 9999901?]

    The WTF goes deeper than that, my friend. After looping through the recordset and finding the record with the correct item ID, THE ENTIRE RECORDSET is passed into the function. No global variable is set and no other parameter is passed to let that function know which record to use. Presumably, SendItemToTransmitter loops through the entire recordset AGAIN.

    WTF indeed.

    Aparently, you are not familiar with passing by reference, are you?  the entire recordset is not sent anywhere, just a pointer.  And a recordset has a "currentRecord" concept, so the current record is available to the function.  Passing a recordset object to a function is very, very common and much preferable to using global variables, which is generally considered poor programming style.

    Not understanding basic concepts like this is often how many WTF's are born ... 

    (edited to fix some typos) 

    You don't see the calling function so you cannot assume that they where smart enough to use byref. Visual basic defaults to byval passing.

    also, upgrade to Firefox 2.0 it has built in spell checking, cause you still have that word spelled wrong.

  • dwayne (unregistered) in reply to John Bigboote

    How many of TDWTFs go back to the core problem of nepotism.  It might as well be a captcha ;-)  Whenever a sentence starts with, "He searched high and low to find the most qualified people..." you know he finds a blood relative.  When will companies learn. 

     

    Captcha: perfection. 

  • John Bigboote (cs) in reply to mrsticks1982
    mrsticks1982:

    You don't see the calling function so you cannot assume that they where smart enough to use byref. Visual basic defaults to byval passing.

    also, upgrade to Firefox 2.0 it has built in spell checking, cause you still have that word spelled wrong.

     

    Are you sure you want to be the spelling police, there, chief? :)

  • boflexson (cs)

    As a contracter once, I got fired for not coming in for the 2am wake up call.

    -Adam

  • bob the dingo (cs)
    Alex Papadimoulis:

    In his half-awake state, Ivan had no idea what they were talking about. Did they want him to come in like Sherlock Holmes and use his oversized magnifying glass to solve the Mystery of the Missing Screw? Sure, he had his drop-step pipe ready, but how was he supposed to get his overcoat and deerstalker hat from the cleaners at such an hour? And then it hit him: the warehouse application probably crashed and they needed him to run a few database queries to find out where the screw was stocked.

    In many warehouses, a delayed order would not be reason enough to wake up a developer, especially a contract developer. However, this particular warehouse stocked millions of airplane parts that were urgently requested by inbound and outbound flights. They called Ivan up because a gate-full of passengers were anxiously waiting for their already-delayed intercontinental flight to depart. A single screw was all that was needed to finish the routine maintenance and send everyone on their way.

     

    i kept waiting for the "but i got there and all they really needed was to find a screw for the case for one of the servers they had opened up." that would've been classic. 

  • GrandmasterB (cs)

    Alex Papadimoulis:
    one of the nephews deployed a new version of communication module shortly before he left for the day.

    This, more than anything else, is the mark of an amateur. 

     

  • ammoQ (cs) in reply to Joel

    Anonymous:
    Sounds like an old legacy app at our company that uses dBase files.  When the thing you want to search for has no index, it's time to iterate record by record (as SQL isn't available).

    Which is exactly what the database engine would do anyway, SQL or not. 

  • kmactane (cs) in reply to ResidentialEvil
    ResidentialEvil:

     Translation: "Don't EVER make me look bad again by going in and fixing code only a moron like myself would write! My appearance as a great developer is much more important than actually getting things accomplished!"

    I actually read it more as "Oh, shit, this guy's been looking at my WTF-ridden code. He might figure out what a loser I am, and I can't have that happening!"

    But they may be functionally equivalent.

     

  • kmactane (cs) in reply to KattMan
    KattMan:

    My usual response to this: Fine I'll go roll back the change.  They immediatly stutter.  Of course 5 seconds later I quit, but never have they rolled back the change.

    Sounds like a fabulous response, and I'll have to keep it in mind in case I'm ever in a situation like this. The one problem: it only works if the client is using source control, which is not a given in WTF-prone workplaces.

     

  • ammoQ (cs)
    Alex Papadimoulis:

    [image]One of the advantages of being a contractor -- well, aside from getting paid nearly twice as much -- and aside from not having to work unpaid overtime -- is that being "on call" is generally not part of the job description.

    I beg to differ.


    In many warehouses, a delayed order would not be reason enough to wake up a developer, especially a contract developer.

    Far from truth.


    It turns out that bringing millions of rows down from the database into a VB application just to look for a single row is a bit slow.

    (Emphasis added) Must be a hell of a warehouse. The warehouses I know (and I know a few of them) contain between 5K and 200K stock items.

     

  • YADBA (unregistered)

    I can beat that.


    I worked for a book publisher, on a system to keep track of book "adoptions".  Big big project. This program was for sales, editorial, and management.  You could tell it which book you were interested in, for which particular sales region, and it would tell you all the opportunities for that area.  I did the initial design, a little bit of tuning, then left it with the contractors (and I have another story about them for another time) to build the front-end, take the credit, etc.  After all, they were "the SQL Experts". 

    It came out.  And it was slow.  Gods, was it slow.  It would run for hours to get details - and while people were fine with that, "could you make it just a little faster"?  So I went looking.  Turns out it would take half an hour for each criteria or member thereof.  One school & 1 book?  Half an hour.  Two schools and 1 book?  An hour. 50 Books and 50 Schools...

    Crud.  So I went through and tuned some more.  Got it down to 7 minutes, since _this_ was the report that mattered, as opposed to the other ones which I had been told were more important during the design phase.

    Seven minutes was better, but I still couldn't figure out why it took so long (the main table wasn't terribly large), so I went and spoke with our inhouse web guy.

    It took him about 30 seconds to spot the problem in the code. The contractor's code would do a "select *" on each table involved, join them manually (by slamming them together), and then check to see if it met the criteria.  Our web guy estimated it would run 2 million times for 1 book for 1 store. 

    He changed the VB code to include the criteria in the select clause, and we went to a flat 2 seconds per query.  And for once, we were heroes.  See?  A WTF with a happy ending!

     




     

  • Pig Hogger (unregistered) in reply to ResidentialEvil

    ResidentialEvil:
    Sadly, I've had a few encounters like this; fix a problem that was holding up a lot of work, and the problem being someone higher than me wrote crappy code, only to get scolded for "not consulting with me" or "possibly screwing something up". And of course pointing out it was already really screwed up only made them more angry.
    Indeed. I once went to a client’s. Boss said "Bring back his system so we fix it in here". So I go there, see the problem was trivial (piece of paper in printer sensor), so I fix it, make sure it works fine and the client is happy, then head back to work only to get shit "we were supposed to bring back the system here to fix it. Now the client thinks we don’t keep our word!!!".

    This is one of the few things that made me glad the company folded a few weeks later…
     

  • Jeff S (cs) in reply to mrsticks1982
    mrsticks1982:
    Jeff S:

    Aparently, you are not familiar with passing by reference, are you?  the entire recordset is not sent anywhere, just a pointer.  And a recordset has a "currentRecord" concept, so the current record is available to the function.  Passing a recordset object to a function is very, very common and much preferable to using global variables, which is generally considered poor programming style.

    Not understanding basic concepts like this is often how many WTF's are born ... 

    (edited to fix some typos) 

    You don't see the calling function so you cannot assume that they where smart enough to use byref. Visual basic defaults to byval passing.

    also, upgrade to Firefox 2.0 it has built in spell checking, cause you still have that word spelled wrong.

    he he , posts like this crack me up ... yep, you got me.  boy, am I embarrassed.

    By  the way, I know the topic is proper spelling and grammar on internet forums, but if I can go on a tangent, I might point out that you are STILL wrong:  a) due to the usage of the recordset class, we can be sure this is pre .NET, with byRef as default,  and more imporantly b) passing object variables by value still results in just passing a reference to the object, not the actual binary data stored with the object.  You can't make the variable passed in point to a different object, but you can still access and change the calling object. 

     

     

  • jspenguin (cs)

    If the site seems slow, it's because it's being farked:

    http://forums.fark.com/cgi/fark/comments.pl?IDLink=2479038

  • Ben (unregistered) in reply to mrsticks1982

    You don't see the calling function so you cannot assume that they where smart enough to use byref. Visual basic defaults to byval passing.

     

    Actually, VB defaults to ByRef.

  • Saladin (cs)

    Dumb: "SELECT * FROM [Inventory]"

    Dumber: Using the above query when you're looking for only one row

    TheDailyWTF: Reading through all the way until EOF for every single query regardless of whether or not the row you need has been found already

  • John Bigboote (cs) in reply to jspenguin

    jspenguin:
    If the site seems slow, it's because it's being farked:

    http://forums.fark.com/cgi/fark/comments.pl?IDLink=2479038

     

    I'm farkblocked. What has been deemed worthy of fark attention? 

  • Demaestro (unregistered)

    If it were me..... after getting sh!t for saving the day I would have said "No problem I will never come in again in an emergency" Then I would have gone in and undone the fix and would refuse to offer any insight if asked on how to solve this timing out problem.

  • akatherder (unregistered)

    They could speed things up by purchasing more "robust" servers.  If it was just failing on a timeout, just change the web server config to increase the script timeout.

     Geez, this stuff is easy.

  • elKodos (unregistered)

    The contractor got what he deserved, it seems to me.  The problem appeared to be caused by a last-minute untested change, but he thinks his own ad-hoc change is infallible.  Fixing code in emergency mode is risky, fixing someone else's code even more so.  He should have got the warehouse going in as conservative a way as possible.

    IMO, minimum risk would be to (1) do an inquiry (using SQL admin tools if necessary) to find the part, (2) advise the warehouse to pick it and ship it without system involvement, if necessary -- there's always a way, (3) advise the warehouse to do whatever inventory and billing adjustments were necessary the following day once authorized coders knew of the work-around, and (4) write up a quick summary of this work-around to submit to the boss the next day.

    Some adjustment to this 4-step program might be needed if it seemed that the system would be hanging repeatedly through the night on other parts, but in this particular emergency situation, the principle of minimizing risk seems to trump the principle of minimizing work.

    If he plays it that way, likely he doesn't even get reamed for unauthorized hours.

  • Sean (cs)

    Ivan put his manager's dick in the dirt. Of course he got reamed for it.  Showing up your boss usually doesn't end well.  And neither does trying to avoid stepping on his toes.  It's a no-win situation.

  • shaggz (unregistered) in reply to GrandmasterB

    I would bet my paycheck that he tested versus a developmental database that had 100 or so rows in it.  Since it worked fine there, roll it out and roll on out of there.

  • shaggz (unregistered) in reply to John Bigboote
    Comment held for moderation.
  • Sam Thornton (unregistered) in reply to elKodos

    <i>Fixing code in emergency mode is risky, fixing someone else's code even more so.  He should have got the warehouse going in as conservative a way as possible.</i>

    Have to agree on that. Here's my analogue WTF.

    Working as a contractor, got called in to fix a little problem with a VB app that a software vendor had sold to a major online brokerage firm. It had been written by really bright guy who'd just finished his MBA, but who had actually never been exposed to programming. To give him credit, he actually produced something that, while clunky and confusing, mostly worked without blowing up.

    Every month, the brokerage used the app's batch import feature to add 100,000 to 200,000 customer records to their SQL Server db. The problem was that even though they had let this process run continuously for up to 10 consecutive days, it had never completed and when they finally aborted it, no records were actually imported.

    Same kind of deal. The app looped through the import file, built a single new record and then opened up a new connection to insert just that record, never disposing any connections.

    The vendor didn't want their customer to think they'd sold them a messed up app, so they wouldn't let me fix the VB app. I wrote them a separete 'optimized batch processor' app that fixed the problem and they cheerily sold it the sucker--I mean client.

  • reptar (cs) in reply to Jeff S

    You're kidding, right?  Even in VB.NET (or VB6) when is it _ever_ appropriate to do garbage like that?  This mentality of coding by banging the keyboard repeatedly until it compiles is a plague that infects all sorts of system.  Although I do agree that using a global variable is bad, so it passing a recordset back and forward.  Write in _one_ place the method to obtain an item by ItemId.

     

    By the way, I once inherited a C# system where the people who originally coded it "didn't like this new ADO.NET thing" and wrote their own "data layer" which wrapped up ADO.NET and put a record cursor on it so it worked exactly like Recordset.  Then they inherited this object into "business object" where they added additional methods to do "business functions".  The whole thing was a huge unmaintainable piece of garbage that I did my best to keep running, while suggesting that if their current code couldn't support 10 simultaneous users then perhaps trying to sell to organisations with predicted 100000 simultaneous users is probably not a good idea.  It ended up in a very similar situation to this where I fixed something very similar to this WTF, and then got told off for fixing it.  My reaction was "Fuck off" and I walked out the door and had a job offer elsewhere by the end of the day.  To this day that company are still struggling with that pile of crap.

Leave a comment on “The Mystery of the Missing Screw ”

Log In or post as a guest

Replying to comment #:

« Return to Article