Consulting for Additech
Additech is a company in Houston that makes fuel pump value-add
sales devices. That's my version, you can visit their website if you
really want to and get their deal (excuse me while I don't link to
them). Their CTO, Richard "Rick" Kemp, was living in Scottsdale and
had taken on the position at Additech after they had a management
change. It's the old story, a new president comes in to try to save
the place, and he or she starts hiring their past associates... not a
bad thing, and not rare.
I met up with Rick at a Borders Books in Scottsdale, we went over
the task, and I signed a consulting agreement. The task was to
develop internal-use tools and I considered it to be a more nerdly
version of "errand boy" for Rick. I would report to him directly.
So far, so good.
Rick carries his cell phone around at all times and is fond of MSN
Messenger and phone conferences. He would setup a phone conference
via an email message (sometimes sent from his phone), and then send out
an MSN Messenger notice when the call was cancelled. For a while the
calls were almost every day, but that quickly fell back to weekly or
less-frequently. I was always the first person on the call, and more
than once found myself waiting on the line until the suddent cancel
alert popped up on my screen. I actually had to get an MSN client for
my linux machine just so I could find out when I was wasting my
time.
Additech has several gas station clients, and at each client they
have one linux server and then various embedded Windows NT LCD panel
computers at each pump station, so that customers can select varous
fuel additives and the system can manage the dispensing equipment and
the purchase transaction. All-in-all, a cool system that I was rather
impressed with.
Managing updates across what was something like 50+ client locations
was interesting. They only had dial-up access, for various reasons,
so they had a server with the locations, phone numbers, and logins at
their office and any communications with the remote machines would
occur through there, via uucp, telnet, or ftp. They were using debian
stable on the boxes.
One problem-- in my opinion-- was that the person they had running
the systems was not a command line person at all. Whenever I would
ask him a question (and whenever he would choose to answer...) I found
that his understanding of the process and tools was completely rote.
He had no intuition whatsoever. On Rick's request, I learned how to
accomplish the tasks that this guy was handling so that i could perform
them if need be... this meant a late-night manual update process
sometimes, where each of 50+ systems would need to be dialed and
managed via telnet.
At one point, I had to apply some configuration changes to all of
the machines manually, so I wrote a perl script to connect to each
machine and issue command lines over telnet, logging the results.
That worked out okay, and the fact hat it was automated meant that the
four hours it took to accomplish were not my four hours...
My main task, initially, was to develop a tool in Python to analyze
the log files that were generated by the pump panels, so that they
could determine when a panel had a failure of any kind. Failures
could range from additive dispensing problems to user interface hangups
to POS terminal transaction issues. The log files were not
human-readable at all, and error conditions were not necessarily easy
to spot. Parsing the log files was a largely-manual task handled by
that same guy who did the rote command line system management, and a
lot of what he knew was not properly documented. Fun.
As I was developing this tool, I had no real intutive feel for
whether it was working or not. That is, I could output errors that I
parsed, I could output information in a particular format, and it
appeared to be working, but I had no way of knowing that for sure.
There was no easy way to QA the tool on my own, so I had asked Rick,
this other guy, and in fact anyone there at Additech if they could tell
me if what I was doing was working and whether it was displaying
information in a useful way.
I may as well have been asking them to disclose their most personal
secrets, because getting an answer to those questions was an impossible
task. In fact, I never got any QA-type information at all, other than
from Rick, who said he used the tool all the time and it seemed to work
for him. "Seems to work" is a Microsoft QA grade, isn't it?
Working with Additech was becoming more and more difficult, and this
came to a head in July when a friend of mine from silicon valley was
visiting here for a conference in Scottsdale. The conference was
early in the week, and he would be staying over from Friday to Sunday
night.
Rick left me a message or sent me an email or something and
basically ordered me to purchase plane tickets for 6:30am Monday
morning to fly to Houston for the week. Hmmmm.
I told him that my friend was visiting until Sunday night, and that
leaving on Tuesday or at least not at that hour on Monday would be much
more convenient, and I was told not to drink so much Sunday night.
Huh? I asked what the agenda was for the week, since I was being
ordered to leave my home for 5 days on very short notice, but I was
never given a reasonable answer to that one.
What I did learn was that their chief architect, a guy named Chris
Cashman, was going to be taking some time off or had too much to do or
something, and Additech was taking on a new major client. From what I
gathered, they wanted me to meet with them or at least be on site to
learn enough to be able to take on some part of this project.
Apparently I would be traveling to Houston frequently in connection
with this effort.
The problem?
I didn't agree to this. As is typical with tech contracts, the
original task is forgotten as the client company decides they need more
and more services at the original price. Working on management tools
or other gopher tasks is one thing, working on company code for
shipping products or services is something very different... their
workflow process being what it was, I knew the task would be difficult,
and surely the stakes would be higher. The pay rate would have to
increase.
In the end, Rick didn't seem to want to share the reason for this
trip before I left, so I didn't go. I was extremely uncomfortable
with the way the whole thing unfolded, and I told Rick that. What did
I get for my troubles? I got stiffed by Additech, to the tune of
$1800.
More tuition, and on to the next gig.