05.29.07
‘Crappy Jobs’ or ‘How I Learned to Stop Worrying and Love VB6′
As a software developer, I’m often faced with the daunting task of “dealing with customers.” At my job, “customers” are usually those who work in my office for my company in another department. Because we work for the same company, these “customers” believe they can treat me either as
- a moron, or
- the guy who caused all their problems.
A typical conversation with a “customer” starts as follows:
<phone rings — I pick up>
Me: This is Matt…
Customer: <fuming with anger> The app is broken AGAIN! Why can’t we get all these bugs fixed?!
Me: OK, slow down, what app are we talking about?
Customer: It’s the app that <insert name of developer who was fired before I started (and probably for good reasons)> wrote.
From there, things go downhill. It turns out that said previously-employed-by-my-company developer wrote a critical financial application that isn’t working anymore. After a little more interrogation, it also turns out that this application hasn’t been working for nearly 4 months, but everyone in the customer’s department neglected to tell IT about it, all the while becoming daily more incensed at the manual workarounds required to do the work the broken application used to do. I also learn that because this is a critical piece of financial software, it needs to be fixed right now.
Now I try to calm the customer — who I can tell is wringing his hands nervously, worrying about what his boss will say when whatever it is you business people do isn’t done on time — by telling him that I will investigate the issue, but because said unemployed developer isn’t working with our company any longer, it may take some time for me to pinpoint the issue, but I’ll keep him posted of any major developments. This is hardly ever enough to please a customer. For some reason, customers feel that IT should have a magic wand that will instantly diagnose and solve any number of issues relating to hardware, software, network problems, or general user error.
Now, I get to the fun part — DEBUGGING SOMEONE ELSE’S CODE! I don’t know if you’ve ever tried to read a bad programmer’s code before, but it’s like trying to decipher the Da Vinci code while someone is pouring bleach into your eyeballs. The fact that the application is written in VB6 only exacerbates the problem.
After about 3 hours of stepping through countless GoTo statements and decompiling DLLs only to find out they return CONSTANTS (yes, I actually had to decompile since our no-longer-employed programmer friend believed in not checking code into any sort of source control system), I track the issue down to a hard coded server IP address that is no longer pointing to the correct database. I’m tempted to start rewriting the entire program so the next unlucky soul won’t have to live through what I did, but I put it off for another day to save time and get the application fixed for our endlessly patient customer who only called me 17 times during my ordeal.
I get the new EXE built and deployed on the 12 different terminal servers my customer’s subordinates use, and I call my customer to proclaim proudly that his super urgent need has been met and the critical financial application is ready to be used! Just as my excitement is peaking at the thought of fixing a problem and getting a “win” under my belt, my customer lets me know that he had his people go ahead and do the manual work around this time, but he’ll be sure to let me know if they have any problems the next time they run it — at the end of the NEXT fiscal year. Massive disappointment abounds.
They should let programmers drink at work.
