It was a pretty fun project. They sent us sample data in Excel, and I learned enough VBA to write a nice little program in Access. Basically, you click a button to start the import, and it asks you where the Excel file is, sucks the data in, determines what data is duplicate and what data is new, asks you if you want to update existing records, then if you want to add new records, does all of those things, and outputs a form of log letting you know exactly what was done.
Unfortunately, after Rick (the client) had a chance to play with what we sent him, he sent Jim this email:
Looking back on our initial email, I thought we were looking at a loading process from our production database into the Aries database. Both are in Access so it would seem that there should be a way to link the tables with some type of load query. Your current load process is workable for other areas but it would be a huge benefit if the we could do this loading internally within Access.Apparently what he had wanted was an import from one Access database to another, not from Excel into Access. Although this is not a gigantic change, and is in some ways easier to code, it wasn't what I thought we were doing.
And at first I felt quite annoyed with Rick. Why the hell would you send sample data in Excel if you weren't intending to import the data from Excel? I mean, I worked with what I was given. Stupid client!
But, no. This is actually my fault. I mean, I have most of an entire degree in software engineering. I know better than to just go off half-cocked and write a bunch of code without doing even a minimal amount of requirements engineering. (It's probably not appropriate to write up an entire set of requirements for this project, but a simple email to the client clarifying his needs would have been prudent.) It is not the client's job to know how to unambiguously ask for what he wants.
Stupid consultant! ;-)
2 comments:
I will say, possibly in your defense, that it always seems trickier when there is a middleman like Jim. I've been Jim in a situation like this before (at the market research company). Not sure how much interaction you had directly with the client, but it sounds like not a lot.
The first time I (as Jim) invited the programmer on a conference call with a client to hammer out specs, the head of programming was immediately suspicious about what was going on. It took a moment for her to get a grip on the fact that I wanted the programmer there from the beginning and so he could ask questions of the client because our office didn't work that way. A lot of offices don't.
So I will add: It's Jim's fault, too! :)
Yeah, the fact that I am not in the habit of talking to clients (whose phone calls I am at least allowed and often encouraged to actively refuse) did not help.
Post a Comment