How not to start a morning

Ovid on 2003-03-04T18:34:39

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.)


Bill 'em!

TorgoX on 2003-03-04T19:46:50

We get to bill them for debugging their bad work.

DO IT!

You Can Lead a Horse's Backend to Water

chromatic on 2003-03-04T20:11:30

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.

Take 'me for all you can get

ajtaylor on 2003-03-04T22:22:05

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 extra money you get to bill them for finding/fixing their stupidity is worth your sanity. If it is, enjoy the extra cash. If not, wait... that's probably not your decision anyway. ;-)

Re:Take 'me for all you can get

Ovid on 2003-03-04T23:02:45

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 validation was in the original bid but I was asked to remove it to keep their costs down (ha!). Knowing my code is incomplete is what really gets under my skin.

Another problem is a matter of reputation. If things go wrong, regardless of whether or not we are our fault, we get associated with problems. Given how frequently these problems occur, I am hard-pressed to believe that Joe Programmer out there is telling his boss "Sorry. I was stupid -- again -- and cost us hundreds of dollars -- again."

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. I suspect that this problem is more prevalent than people think (and now that I think about it, I wonder how many of us have products whose quality is lower because some poor programmer gets repeatedly pulled away from working on it due to issues like this.)

Re:Take 'me for all you can get

chromatic on 2003-03-05T01:11:12

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 thing altogether.

Re:Take 'me for all you can get

ajtaylor on 2003-03-05T04:49:06

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've found & resolved a workaround w/ another employee or it was human error. Yes, this probably means at some point I should revisit some of these "problem" areas and make sure they don't happen in the first place. I've heard the sighs a little to regularly, but often don't have the luxury of fixing them. :-(

Point 3: Agreed again. For me, it's often difficult to get into a groove. Those are the days I work a little late because I don't want to lose the momentum. This is not expected (and often not noticed except for CVS commit logs), but I do it because it's better for how I work.

Even if the new request is _very_ simple, I lose time having to figure out what I was doing (and since I'm a good programmer I try to add comments to aid the next person who comes behind me), fix it, test it, and launch it. Even for trivial requests it's at least 1/2 hour. So more complex things ofter get pushed off just because it would break my existing schedules. I'm fortunate in that I have few _hard_ deadlines because everyone prefers a well-designed & implemented application. But I know people get annoyed nonetheless.

I think for me Point 2 is the most important. My company is small, and I can't afford to be known as the guy whose apps are flaky. That reputation doesn't get me raises! :-)

Re:Take 'me for all you can get

dws on 2003-03-05T07:41:13

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.