Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

The Drama of Being a Developer IV - Quality is something else altogether

by cacharbe (Curate)
on Sep 30, 2002 at 21:24 UTC ( [id://201853]=perlmeditation: print w/replies, xml ) Need Help??

The continuing story of a developer and his quest to solve the problems of business without having a major break from reality.
For parts one, two and three, read here, here and here.

What follows is yet another harsh lesson learned about projects in the corporate world, be they programming, or otherwise.

Chapter One

- Can someone please define Quality?

When we last left our intrepid hero, he was neck deep in a Portal Implementation, and while he juggles that peril to the amazement of the onlooking masses, he has found himself embroild in yet another corporate SNAFU. A while back, our Hero was asked to attend a meeting to be a neutral set of eyes and regarding a reporting application that his group was going to undertake. When he heard the method that was being used to aggregate most of the data being used for the reports he screamed (internally), he roiled (in his brain), his blood rushed to a boil...But calmly he asked..."Come again?"

First, a little back ground. Our hero's company as group named the Quality Group (the irony of THAT name will become clear in a moment). Their job is to work with the plants and their customers to indentify break downs and problems in production that cause costs to increase further down the line...AND FIX THEM. Each morning, worker-bees from the group in question went out to their three most important Customer sites (The Big 3) and began the long and arduous process of cutting and pasting data from the web sites to Excel Spreadsheets for reporting. This data reflected the company's performance as a whole, as well as on a Site-by-site basis. The process took 3 people ALL DAY to accomplish. This group was supposed to be looking for and fix break downs in quality and production, and all they had time to do was create reports.

Needless to say our hero was appaled

Much to the suprise of everyone in the room (including his own), he volunteered to look at making that process a little more streamlined.

Six months later - after a continuous head-ache, bashing his head against his desk and momentary lapses and breaks from reality, he worked with the team to write code that automatically downloads the data and created a process with which all of this speedily slurped data could be entered into a back-end database for the enterprise level reporting application that was purchased (and the oneous of the original meeting) to report against (they didn't want it to go directly to the database without some human intervention - read: Massaging it is, ater all the Quality group). After 8 months of work, a process was in place, and now, with the click of a button, and a game of "follow-the-link through some important questions" one person can get all of the data through an intranet-based perl application. Just Click-Click-Click, and go get some coffee. When you return, the reports are deliverd in full color to your inbox for sharing with your friends, family and the VP down the hall.

obPerl: If anyone is interested, I have some robust code for downloading PPM, WC, QR et al. and Key Indicator data from GM, Ford and DCX supplier sites, all nice and wrapped up in an OO bow

Of course, this process is in constant upkeep because of the little changes to the customer sites that require subtle shifts in our hero's code, but we digress.

Chapter Two

- A new Project?

Shift ahead a few months, a few changes in the code, and some small add-ons to make everyone's life a little easier.

Our hero is working in realitive bliss on his primary project when he suddenly takes part in an ethereal phone call that sounds something like this:

Our hero: "Hello?"
Them: "Are we on target?"
Our hero: Coming out of coder-daze(tm) "Huh?"
Them: "Are we on target for roll out?"
Our hero: Thinking, maybe they dialed the wrong number. "For what, exactly?"
Them: "The data parser and database code you are writing."
Our hero: It was at this point that our hero started quietly looking for the EJECT button. "Come again?"
Them: *Brief, non-technical description of what they understood our hero's fictitious code was going to do*
"So, are we on target?"
Our hero: WTF!?!?! Okay, Chuck, play it cool, play it calm...."When the hell was I supposed to find out about it!?! I bet you're thinking that you've let the cat out of the bag early, but you just couldn't contain yourself any longer, eh?!?"

You, belov'd reader, can probably imagine how the conversation proceeded from there. Although no one feels that our hero is to blame for the gross miscommunication (there's a lot of upper level finger pointing still going on three weeks later), it doesn't change the fact that these people had(ve) an Oct. 1 roll out plan. *sigh*

No pressure.

It turns out that there is another part of this Multi-tier, multi-platform, enterprise level application rolling out to the first 25,000 users (out of a potential 60k) in the near future, and our hero was told that he had a major part of it to write (about 8 weeks worth of work), 4 weeks before the roll out and 5 days before his deliverables were suposed to be due. It seems that SOMEONE put his name on an engineering schedule to write code for something, and EVERYONE failed to tell him about it. Go figure.

Chapter Three

- Day four, we searched for intelligent life...and failed.

Jump ahead a measley four days..four days into our hero's mad dash marathon coding. 600 lines of working Excel Parser code, Oracle dB code, and verification/business rules code that would make your eyes bleed. Four days of blood, sweat and...well, you get the point.

When what to our wondering eyes should appear, but a gremlin in the form of a manager, dear. He had changes to the specifications that he needed in a flash (Our hero felt like tearing open his chest and eating his heart from the gash). The parsers would need changing, the dB tables rearranging (and of course the target date wouldn't be changing).

All the while, our hero is supposed to be going out of town for two planned long week-ends (planned, in advance, for 3 months).

No pressure.

Chapter Four

- Last Minute data changes, and no-one's home.

So here our hero sits at 5:15pm EST on Sept 30th, the people who want this rolled out, his managers and the dBA have all vanished, and the data that he is trying to upload doesn't conform with the initial templates, and subsequently all his coded business rules, and the constraints on the dB. He's left voice messages, emails, text pages and smoke signals to everyone who might care, and no one is responding. The users' data is FUBAR, and he has no recourse. So he's going home.

I hope I have a job tomorrow. My fault or not, I've always known that I'm the whipping boy.

C'est la vie, C'est la geurre.

Lesson: You are never finished. You cannot trust nor enjoy the calm moments, for there is always something brewing that you forgot, missed, or weren't aware of.


Update: Thanks to ehdonhon for bringing to my attention that I had forgotten my lesson (so soon) in my haste to get the hell out of dodge.

Update II: Added READMORE tag. Should have done that from the beginning

  • Comment on The Drama of Being a Developer IV - Quality is something else altogether

Replies are listed 'Best First'.
Re: The Drama of Being a Developer IV - Quality is something else altogether
by ehdonhon (Curate) on Sep 30, 2002 at 23:26 UTC

    I'm not sure if this fits into the "Its funny because we're all happy it isn't us (this time)" category, or the "Its funny because we all know its true" category (either way, I give it a ++). I suppose we've all been in that position at one time or another. Personally, I think it's just a symptom of pointy-haired boss syndrome.

    You started out your article by saying:

    What follows is yet another lesson learned about projects in the corporate world, be they programming, or therwise.

    I know I've already drawn my own conclusions, but I'm just curious what the actual "Lessons learned" were from your perspective?

      The lessons are deep, varied and (for some) unprintable. Thanks for the heads up.


      Flex the Geek

Re: The Drama of Being a Developer IV - Quality is something else altogether
by talexb (Chancellor) on Oct 01, 2002 at 14:02 UTC

    When I worked at Motorola (back when a 300M drive took two men to carry and was the size of a beer fridge), I was the Design Engineer for a couple of data communications products called statistical multiplexers. That meant I was the Engineering guy in charge of the paper work. What I typically did at least once a week was go for a walk around the plant.

    That meant I'd wander over to Shipping/Receving where the parts came in the door and the finished product went back out, the Stock Room, Manufacturing, Purchasing, the Heat Room (units were burned in for 72 hours at 40C, about 105F), Final Test and Field Service. Along the way I'd chat with people about how things were going. That would give me a heads-up on issues before they become Full-Blown Crises.

    If you're not in a Manufacturing setup and it's just you and 1,499 other cubicle dwellers, you can still do the same thing .. drop in on your boss's colleagues and chat, maybe come across a VP in the hallway. You gotta stay plugged in to what's happening. Get plugged in to the gossip network, not so much as a contributor but certainly as a subscriber. An organization is composed of many personalities, and each personalty has its own set of criteria and priorities.

    Hopefully that doesn't sound too Zen for you. :) Let us know how it turns out.

    --t. alex
    but my friends call me T.
      It's funny. I've had lunch with the two people that put me in this position (my boss and the Quality Manager) a number of times since their meeting, and not once was this part of the project discussed. Not in passing, not even a good-humored "Had enough yet?"

      My boss told me, what would probably be 2 or 3 days after their big meeting, that my biggest priority was the portal now that the project was moving forward (see parts 2 and 3 for more details), and that everything else was secondary. When I approached him about that statement, and asked him how he could, in retrospect, knowing I had that deadline, have made that comment, he shrugged and commented that he didn't know that it was going to be so much work.

      Of course, I didn't know that it was going to be ANY work. He also said that he thought it strange that I hadn't commented on that particular piece of the project at that time either, but chalked it up to me being a team player.


      Since when have I been known as a team player, especially when it comes down to me being someones b#!@%?

      I have to laugh at the situation, otherwise, cf. my "Freeing Organs up to Donors lists" comment in the CB.


      Flex the Geek

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://201853]
Approved by Zaxo
Front-paged by shotgunefx
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (2)
As of 2024-07-19 22:19 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.