Monday, August 14, 2006

Anesthesia Or Something

More hospital dialog:

Lauren (Nurse): Okay, Mr. Fing, we're going to take some blood. Right or left arm?
Me (Patient): Uhh, shouldn't I get anesthesia or something?
Lauren: What, you don't like needles?
Me: Does anyone?
Lauren: My nephew does -- he's a junkie.
Me: [Speechless]
Lauren: How about the right arm?
Me: That's my throwing arm.
Lauren: Oh, do you play sports for a living?
Me: No. I psycho-analyze people and animals.
Lauren: Umm, okay, left arm then.
Me: [Melodramatically] Oh, Lauren, if it's possible, let this cup pass from me, as I don't yet have a will, and I really should have a will.
Julia (wife): Are you comparing having blood drawn to Christ's crucifixion?
Me: I'm delusional from the drugs.
Julia: The Motrin? You've graduated from wimp to something even more sad and pathetic, like some freakish loser.

6 Comments:

At September 21, 2006 11:00 PM, Anonymous Anonymous said...

More hospital stories, Mr. Fing.


On my desk by 5pm or we might have to introduce you to the business end of my booty stick.

 
At October 17, 2006 4:41 PM, Anonymous Anonymous said...

Alright, Fing. Since you're too busy, lemme have a crack at this:

Hotpants finally got the boot. I think he knew he had to go about a year before it happened, so he worked 12-14 hour days every day but somehow managed to keep the project open almost indefinitely with program repairs... upon program repairs... upon program repairs until finally he was just given a date to pull it all together and huff off. He managed to build a structure out of balsa wood and elmer's before receiving the final tap on the shoulder.

Now Bluetree and I are picking up the pieces. Every couple of days we get another 'Hotpants Bomb' from the code he produced over the last 2 years.
Naming conventions:
We'll see date variables in the code like 'WKDAT1' Okay that's easy enough to figure out, Work Date 1, but then later we find another date variable in the same program that's registered as 'PSWTF52' WTF indeed.
Logic:
① The program starts off validating the input fields of the screen. First, making sure that the values for the date are legal and if not, trigger an error flag. Then it goes on to the next field validation and resets the error flag so even if the date is incorrect, the program will never know it.
② Another place he sets up a new physical database table to store fields that are already held by other tables (Redundant data in a database is bad form, he should set up a virtual table for the purpose of that program). Not so terrible, but as time goes on and the fields in the other databases that he's pirated information from change, his physical table doesn't change and the logic he uses says, "If you can't find the requested field, take every single bloody field you can find and stick it in the download file." While modifying this program we run across the tests that he created and it's pure gold. His test data is geared to work with his faulty code. Wow.

Other problems just appear to be simple negligence and probably the result of working during a nervous breakdown. Complete lack of understanding about the way that the users operate, making his code work as long as the user didn't do anything out of the ordinary but blowing the pistons out the engine block when the user pushes Enter instead of Ctrl.

Bluetree and I are slowly turning this code around, sometimes rewriting chunks from the ground up because it never matched the specs in the first place.

 
At October 18, 2006 5:01 PM, Anonymous Anonymous said...

There's plenny more where that came from.

Hotpants Bomb #317
爆弾内容:

問題 Problem:
When making an inquiry into Parts Demand over the last several months, Frequency and quantity of sales along with totals and averages, we occasionally see values like '-50' and '-263' Strange, yes. This obviously destroys our Order Point calculation for that part and leads us to the conclusion that the calculation has gone haywire and we can't trust the data.

調査 Investigation:
Alright, who's been messing with the Sales programs lately? No one? It looks like this problem just popped up in the spring. We've got no idea what's causing this so we have to go into the journal files, one by one, read the HEX code and find out which program is telling the Parts Demand library to go deep into the negative numbers. Deep in there.
Bluetree and I eff around for a couple days until, unbelievably, we find that the Purchase Receiving data program is updating the Parts Demand library. The Purchase program is updating the Sales Demand library. The Purchase program is updating the Sales Demand library. The Purchase program is updating the Sales Demand library.
Now time to dig into the code and figure out where this bomb is hidden, no less than 4 updates to this program in the last year with no reference material available on the specs for those modifications. A clandestine email is shot out to the dearly departed Hotpants and we get the following reply:
"Sorry, there was no Modification request from overseas and no supporting materials for the mods I made. I don't really remember why I programmed it like that... maybe it was to cope with X-dock orders that go straight from Purchase to Sales... Good luck."

原因 Cause:
Not only is Sales Demand being updated using assbackwards logic, but the update is wrong, wrong, wrong. When the item line gets split into separate components, the program goes into a recursive loop and registers negative values for every resulting line item.
例 Example:
An order comes in for a 20 piece kit of some part.
When receiving that part, the system splits it into it's 7 separate components.
If that kit is meant to be shipped directly to the customer, then the program goes through each of the 7 components and adds steadily increasing negative values for each component to the overall sales demand for that part... From the Purchase side of the program.

修正 対策 Modification, countermeasure:
Defuse the bomb.
Repair the data that's already been bent.
Rehaul the entire effing program cuz it's a mess of shithouse modification after shithouse modification.

Did Hotpants do this one to screw us over? Is this the smoking gun that says, "I spent my last months in the company creating malicious programs to get back at you." Either way, he's 40+ yrs old and his life isn't getting any easier. He got pushed out of this job and is now commuting 5 hours a day instead of 2, and if he made these bombs to spite us then he deserved whatever ijime he got. Or did the bombs come as a result of the ijime? Chicken or the egg, I dunno but I never pulled the rug out from under my coworkers over when I couldn't handle the stress.
I thought he liked me!!!

 
At October 25, 2006 2:26 AM, Anonymous Anonymous said...

Hotpants Bomb #324

Not such a big one, but it makes us slap our foreheads and never expect to get a helpful answer from that turkey.

Hmmm, it looks like no one has used this User ID for the last year so we should delete it to clean up the System.

First, research a little bit and upon cursory inspection it looks like no one is using it.
Doublecheck with Hotpants;
"Hey Hotpants, this User ID that you created, it looks like it hasn't been used in the last year. Is there anything we should know about it? Is it necessary?"

"Hmm, no I don't think so. You should just be able to delete it"
(Bwahahahahaaaa, SUCKAZ!!!!)

Within one hour we get a frantic call from overseas,
"Hey, wtf?? The auto-rack inventory system and Parts system aren't talking to each other!! Get us back online!"

Thanks, Hotpants. You knobface, created that ID specifically for the FTP interface between the two systems, even though there's already an ID set up for that purpose. He knows exactly what he's doing to us and loving every minute of it. A pox on you and your house, Hotpants!

 
At October 25, 2006 2:32 AM, Anonymous Anonymous said...

Hotpants Bomb #342
爆弾内容:

問題 Problem:
When a part comes in that has to be split into separate units (i.e. a kit is ordered as one part, then it gets received by it's components: pump, tape, seal, ring, cover) Occasionally... rarely, actually, it seems that one of the components disappears, then the operator gets an error and has to cancel the kit and reorder the components from scratch and request that the parts do not get shipped again from the vendor. Manually calculate the component cost and then store it in the warehouse.

調査 Investigation:
It took us about a week just to get a story on this problem that we could work with. At first they were blaming this program and that program and hypothesizing that the problem is this, no it's that, maybe it could be there, we need extra options on maintenance to deal with this, etc,....
Eventually Blue Tree and I make our way into the online shipping data receiving program to have a look at the logic and see why that one component got skipped. Here's a bit of code--
If ListPrice==*zero and ComponentCode==*Yes Mar15
Print *Error and Remove *Part Mar15
End if Mar15

Hmmm, this seems to be why we're missing the component. The List Price on that component is zero so it belches out an error and removes that item from the component list. The update was performed on Mar 15, 2006.
Funny thing is, I don't remember anything about this specification in the program while working with Hotpants, so I'm searching through past mails...searching...Wow, there's a lot of effing problems to search through... and I find a problem with the program that was fixed in February and another unrelated problem in April... but nothing in March. Blue Tree is looking through the specification and program modification logs... Nothing. Whenever we touch the Live system we're required by ISO standards and our SLA to confirm any changes and get a specific request to make those changes from overseas sys admin. Any modification MUST be accompanied by evidence related to that mod.
We've got no evidence and we've got a rogue modification from numnuts that's burning us right now. Continue investigation by confirming specs from overseas staff and sending Hotpants a discreet email asking how his nervous breakdown is coming along.

原因 Cause:
Aforementioned unjustified code.

修正 対策 Modification, countermeasure:
If you want to get rid of a programmer, empty his desk, disable his key-card access, and fire him all on the same day. Up until then, make it a point to be nice to him and then just cut the hamstring. Tapping him on the shoulder and giving him daily come to Jesus chats for 6 months is not the way to do it.

 
At November 02, 2006 6:26 AM, Anonymous Anonymous said...

When is Dr. Fing coming back? All this chatting by The Dude without proper analysis by Dr. Fing is without merit.

-Nate

 

Post a Comment

<< Home