Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday March 04, 2003
01:34 PM

How not to start a morning

[ #10885 ]

I get to work bright and early. I unlock the office, start coffee and settle down to check email. The phone rings. One of our clients is upset because a Web page which should show money market quotes is not, in fact, showing money market quotes. They want to know how we screwed up.

I take another gulp of coffee and try not to get annoyed. A year and a half ago, I wrote the programs that munge their data. In all of that time, we've only found one legitimate bug in my code (admittedly, the code's pretty simple). I know the problem lies with the client, but once again I have to figure out how they ingeniously screwed up this time.

They were sending us four data sets in three files. Apparently, someone at their end realized that this could be confusing, so they broke out one of the files into two files, but didn't bother to tell us. One of those files contains the missing money market data.

The problem gets fixed by a coworker. Shortly afterwards, my boss walks up and asks me to check into another problem with said data. The client is now complaining that the timestamp on the Web page is several hours older than it should be. I walk to the computer with the data and open the file. Sure enough, they are sending us files with bad timestamps but rather than look at their data, they call us to complain. We get to bill them for debugging their bad work.

This happens with these folks at least once every couple of months. I wonder how they stay in business. (we've already pitched a deal where I spend a few hours writing some validation code that will quickly alert us to anomalous data, but they've refused this repeatedly despite the fact that they've clearly paid far more money for not having this.)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • We get to bill them for debugging their bad work.

    DO IT!

  • One option is to point out the cost of surprise. "Because of this change, the feature I was working on is delayed by a day."

    Is your bill itemized? Perhaps you need a line item that says "6 hours spent debugging surprise data format changes". Financial people just love surprises.

  • These are the sort of clients who won't listen to reason. Have you showed them an itemized list of $$$ billed for fixing their mistakes? And how much larger it is compared to just writing some sanity checks? That sometimes opens people's eyes. And if it's only a few hours, wouldn't it be worth it for your company to just eat the time and be able to call the client first to tell them they screwed up? I've always loved showing someone that the "bug" is really their error. :=)

    You have to figure out if the ex

    "Perl users are the Greatful Dead fans of computer science." --slashdot comment
    • I can't help but wonder if your title was a typo -- 'me versus 'em :)

      We have broken this down for them before but the response is typically something along the lines of "once we nail this thing, it won't change any more" (which, of course, is the reason most of us with jobs still have them.)

      You are correct in thinking that giving up the ongoing revenue from their stupidity is worth my sanity, but I have three other problems with issue. First, I hate to have a system that I know is wrong. The data vali

      • I'm not sure that interrupting your flow is the worst part. To me, it seems more important that you've taken time away from other tasks. If you've been scheduling time for various customers, you've made an agreement with them to accomplish something within a certain time period. Having to respond to emergencies is understandable, but if the "emergencies" happen regularly, they ought to be scheduled as such.

        Of course, if you have a service level agreement with the flammable customer, that's another th

      • D'oh! I hate it when I do that... Where's a spell check when you need one?

        Point #1: I hate having a fragile system as well. It really bugs me that I have to keep tweaking it for no _good_ reason. I had a project like this once at my current job, but I finally bit the bullet and got things right. Life has been much simpler since.

        Point #2: Right on! This also applies to inter-business projects. I'm constantly getting notes about how something didn't work right. 95% of the time it's either a known issue I'

        "Perl users are the Greatful Dead fans of computer science." --slashdot comment
      • The final problem with this is simple: every time I have to fix this, it drives up costs for other customers as I get pulled out of the "groove" and have to spend time figuring out where I was with the work I was originally doing.

        This sounds to me like the customer problem is masking a management problem, or perhaps an impedance mismatch between you and your management. From what you say, they seem a lot more comfortable with exchanging reputation for money than you do.