Workplace idiosyncrasies
Dec. 5th, 2006 10:28 amWhen will I learn to stop going above and beyond the call of duty?
A year or so back I extracted a bunch of records from one of our mainframe flat files and dumped them into a small, local database for quicker access. Since most of the people in our office have no idea how to use MS Access, I built a Visual Basic front-end that allowed them to query the data with a couple of user-defined filters. It worked great until I repopulated the database with fresh records last week. Somewhere in the process it changed my ""s into nulls, and the program quit working.
The solution was fairly simple, but time-consuming. I either had to fix the database, or change the program to handle nulls. Since I will be using the same program to refresh the database the next time it gets out of date, the nulls probably won't be going away, so I opted to fix the program rather than the database. It turned out to be a somewhat fiddly process, and each fix I put in place caused another failure downstream. The fix started taking much longer than I would have liked, and herein lies the problem.
This program is not an official, supported program. This is just a little utility that I cobbled together during my spare time to help some of the people in support positions do their jobs. The program simply cross-references data that they used to have to do manually, using 3" thick physical printouts of the tables. Because it is just a side-project of mine (my boss doesn't know that it exists), I could only work on it when I was caught up on everything else, so it was over a week before I finally got it fixed. Needless to say I had to deal with a small flood of email scuds from unhappy end users.
As useful and time-saving as this program is, I am left wondering if I should have created it in the first place. There are now a group of people who have become dependent on an application that doesn't officially exist.
A year or so back I extracted a bunch of records from one of our mainframe flat files and dumped them into a small, local database for quicker access. Since most of the people in our office have no idea how to use MS Access, I built a Visual Basic front-end that allowed them to query the data with a couple of user-defined filters. It worked great until I repopulated the database with fresh records last week. Somewhere in the process it changed my ""s into nulls, and the program quit working.
The solution was fairly simple, but time-consuming. I either had to fix the database, or change the program to handle nulls. Since I will be using the same program to refresh the database the next time it gets out of date, the nulls probably won't be going away, so I opted to fix the program rather than the database. It turned out to be a somewhat fiddly process, and each fix I put in place caused another failure downstream. The fix started taking much longer than I would have liked, and herein lies the problem.
This program is not an official, supported program. This is just a little utility that I cobbled together during my spare time to help some of the people in support positions do their jobs. The program simply cross-references data that they used to have to do manually, using 3" thick physical printouts of the tables. Because it is just a side-project of mine (my boss doesn't know that it exists), I could only work on it when I was caught up on everything else, so it was over a week before I finally got it fixed. Needless to say I had to deal with a small flood of email scuds from unhappy end users.
As useful and time-saving as this program is, I am left wondering if I should have created it in the first place. There are now a group of people who have become dependent on an application that doesn't officially exist.
no subject
Date: 2006-12-05 07:44 pm (UTC)I would hazard about 40% of my job is coming up with useful little Access and VB tools nobody asked for and no one knew they wanted.
no subject
Date: 2006-12-06 05:55 am (UTC)There sure seems to be a legitimate and valid business need...