Skip to content

DanHugo.com

Sections
Personal tools
You are here: Home » Stories » Back to Arizona » Consulting for Additech
advertisement
 

Consulting for Additech

While I was passing the time at what was my second-least-favorite job ever (Intel), I was actively looking for something different,and was sending my resume out on Monster on a daily basis. I got a call from the CTO of Additech, and after two phone calls, we were set. My last day at Intel was already on the calendar. Finally, some good news! Or so I thought.

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.

Created by danhugo
Last modified 2005-05-23 05:05 AM
Blog
Recent additions:
No blog entries are published.
« February 2006 »
Su Mo Tu We Th Fr Sa
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28        
 
 

Powered by Plone

This site conforms to the following standards: