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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Take 'me for all you can get (Score:1)
You have to figure out if the ex
"Perl users are the Greatful Dead fans of computer science." --slashdot comment
Re:Take 'me for all you can get (Score:2)
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.)
Reply to This
Parent
Re:Take 'me for all you can get (Score:1)
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
Re:Take 'me for all you can get (Score:1)
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
Re:Take 'me for all you can get (Score:2, Insightful)
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.