I’m a FileMaker database geek.
The New Jersey half of the business has their own independent database. Not my idea, I had them unified until one day in 2002 the techno-illiterate but co-owner of the freaking company decided response time was too slow and he wanted the NJ database hosted locally. (Actual problem turned out to be due to bad ethernet switches upsteam by a fly-by-night provider).
So this co-owner semi-boss fellow had brought with him, from his previous company at the time of merger, a silly little flatfile FileMaker database for salesfolks to input potential jobs and print out estimate requests and hand it to the estimating department. Because it was His Baby, I basically incorporated it untouched into the larger FileMaker system used by the company that bought them out, and after the “divorce” wherein they got their own standalone system, I developed the rest of the system in keeping with their needs and mostly ignored the silly sales pre-job system, until one too many change requests came my way and the flat-file architecture just would nto support what they wanted out of it.
BRIEFLY, FOR NON-DATABASEGEEKS: Flatfile means that when the salesfolks want to type in parameters for a possible job that a customer is asking about, and they want estimates for prices for possible run quantities of 2500, 3000, 3250, and 3500, there have to be four fields defined (Quantity 1, Quantity 2, Quantity 3, Quantity 4). If it were relational, there would be another file in the background that would have one field, Quantity, connected by some unique value in the main file, call it SalesRecordID#, think of it as a serial number, and you’d have anywhere from zero to a godzillion possible child-records holding quantities, depending on whether the salesperson entered no quantities, four quantities, or a godzillion different quantities. Now consider that for each quantity there was a % sales markup field (therefore four of them in the flatfile system), and a rate field (four more fields) and a final-price field (rate times quantity plus rate times quantity times markup%) , eight more fields. And a series of scripts that let the salesperson select one possible variation and say, in essence, “The customer wants this one”, and dump that data into yet a fifth set of all of those fields which becomes the source data for the actual job record in the other database which pertains to actual live jobs. See how messy flatfile databases are? Ugh!
So at some point they wanted to be able to handle 8 possible quantities so I had to define four more sockets for each of those parameters and four more scripts (ugh!).
The proverbial camel-backbreaking straw was when they wanted to be able to accomodate more than one variation in type of paper, and more than one variation in binding. And I said, enough is enough. Prima donna company co-owner or not, he’s got to let go and let me bring this silly file at least into the 1990s, with a potential-job file that has child records that are products that in turn have child-records that are quantities that need estimates. So I said so and I came out to NJ and showed them a prototype. And they said “OK”. And I went back and did the actual modifications to an offline copy of the database and came back a second time and showed them and said “It will be different, you’ll have to learn new things, and it will be more complex but it will me much more powerful in terms of what you can do with it”. And they said “Uh huh, OK”. So I finished the last crossing of t’s and dotting of i’s and imported the old data over the weekend and rolled out the new version.
And they fucking FREAKED. The salesfolks screamed to the techno-phobic co-owner whose baby this had been. It’s all different. I don’t understand it. I get lost. (They should have been calling me. That’s what I’m there for). And he called, no, not me, but my boss, and said “Tell him it isn’t working and he has to return it back to the way it was.”
Look here, mister company co-owner. You’ve got a double dozen salesmen but you and your opposite number here in NY have got exactly one FileMaker geek between the two of you and I can out-prima-donna any salesperson you’ve ever met. You lose me, you’ve got to hire another FileMaker geek AND you’ve got to wait while the new person gets up to speed on this particular system…and you know what? You aren’t gonna get someone as good as me. I am the bestest and the fastest. There are FileMaker geeks who are better than me at publishing to the web, or making ODBC connections to foreign systems, or accessing XML data, but when it comes to raw native FileMaker functions I’m the Johnny dude, I’m the best that’s ever been. No one else can write new functions for you as fast as you can describe them over the phone and say “Like that?” and have it DONE by the time you’ve finished explaining what you want done. And I do not have to work for you.
But it did not have to come to that. I went out to New Jersey today to make the old version live while making it clear to him and the other salesfolk that the old version would NOT be developed any further, that it was strictly a stopgap measure until I could give individual tutorials to each user…and Mister CoOwner explained one of the reasons he didn’t like the new system and I re-explained how to address this problem and this time he got it and that one feature, by itself… “Hmm, so I just clone the product? And when I’m done all the differerent variations can be viewed as part of the same potential job? And all I have to change is what’s different?” …so he said forget making the old version live. He agreed that I should sit with each salesperson and give them indiv instrux until they feel comfy with the new system. Beginning with his admin assistant who does his own input work for him.
Which is all I ever asked for.
Previous Note: http://boards.straightdope.com/sdmb/showthread.php?t=317672