My candle burns at both ends

My candle burns at both ends
It will not last the night;
But ah, my foes, and oh, my friends -
It gives a lovely light.

-Edna St. Vincent Millay

Someone mentioned that poem a while ago (and I do mean a while – so I’ve been a negligent poster for a just a little while, and I rather liked it. The idea also fit me for a while – I was waking up early and going to bed late. There may have been reasons – one of my projects was truly balancing my checkbook for the first time in seven or eight years. A rather daunting prospect, made a little easier with some experiments in Ruby In the process, I discovered a few things – I was off by about $200 (thankfully such that I thought i had more money than the bank), when in doubt, the bank is right, and as to my original cause for inquiry, I was right. The invoicing was off for my organic produce delivery service. I think that they did not process the invoice for an accidental shipment. I informed them of the error and nothing happened, so either they didn’t believe me, or figured it was their mistake so the food was free. Of course I had to make a ‘free money’ entry (right after all the error corrections for the balancing) to offset my original deduction.

The other big event was attempting to change ERP (Enterprise Resource Planning) systems at the company I work for. Unfortunately, the entire project was a little doomed from the start. A topic which, as I write, I see will turn into an extended digression.

So The Boss says we need change systems. Our current system is an industry specific package (I’m not going to get into the specifics), written in FoxPro. FoxPro itself, is, from what I can tell, fairly good system for database applications – on single computers. The model for extending it to to networks involves copying entire database files across the network – and if modified, copying them back to the server. This means it is both slow, and prone to occasional database error. The database is reindexed every night, and the program will actually warn you (with reason, we’ve found) if said process hasn’t run in 48 hours. Some errors still get through.

At least in the version we have; supposedly most of the problems have been worked around in the current version of the product. Unfortunately, in the murky past mostly before my time, the powers that be decided that the system updates were introducing more errors than they resolved and broke off relations with the vendor. Since then we’ve basically learned to put up with and work around the major shortcomings, and business gets done, albeit with vastly less efficiency then possible.

So, to recap, The Boss has realized that this can’t go on forever (hand crossed-out entries on accounting reports just don’t look so good, you know?) Meanwhile, I”m a little short on programming projects and see a problem to be solved. So begins a year or so of cursory evaluation of a good proportion of every system that might fit our needs. Of course, when you get down to it, I have no idea what I’m doing, nor does anyone else involved. Which isn’t much. The Boss decided it should be done, and I set out to do it, with some assistance from a co-worker. The rest of the people at the company aren’t bothered by the accounting errors much and have gotten used to the current system – support for evaluation and testing has been extremely minimal.

I’m wandering a bit, but I’m trying to keep a very long story not so long. We eventually choose a system. (Global Shop) It appeared to have a wide range of features, some of our people thought it looked best of the short list, and they had a quote to develop some of our industry-specific functionality. Of course, from what I’ve written above it should come as no surprise that we made at least our fair share of beginners mistakes in choose a system. To skip ahead a bit, Global Shop developed out of a metal job shop market. This a labor intensive type of business. We, as circuit board assemblers, are a materials intensive type of business. We knew this going in, but didn’t realize just how deep this issues was. In the end, the inefficiency of the stock room systems had us so far behind that we had to shut down they new system and continue on with our old one.

That was mid-January. The ‘go-live’ date handed to us was was the beginning of December. This of course made no allowance for the lack of testing support, or the incompleteness of data conversion. Actually the data conversion was ‘okay.’ I found a bunch of Perl database modules and set up a nice little conversion system. I also ran into a lot of Perl’s rough edges, and, provided equivalent modules might try such in thing in Ruby if starting it today (the regular expressions being a big draw to both languages)

But I digress. The point, at long last, is that there was over a month of system investigation, user support, live system data patching, and report writing. The great flood of issues nobody could be bothered to discover beforehand had me in early, out late, often in on weekends. The odd thing was I kind of enjoyed it; something, perhaps only a little, seemed like an aspect of my true calling. Something about people, who I know, suffering inconveniences (which I am in some part responsible for), which I, somewhat uniquely, have the power to resolve. As for the weekends, I would often get up and start trying to read something, only to find I was thinking about the current problems instead of what I was reading. If I was thinking about them anyway, I figured i might as well fix them.

Sometimes I think that my current practice of flitting from from one activity to another is sub-optimal; I often like to dive into a project and forget about the world for a while.

Comments are closed.