"Small" was no exaggeration. When I signed on, the company was the owner, the owner's wife and me. I was working as a contractor, which suited me fine as it meant a reasonable salary and a good income. It was initially quite exciting. They'd had some guy working on it before me who had left suddenly. (Had I been older, I would have inquired as to why.) There was probably about a month's worth of code laid down. Enough to prove the concepts but little enough that there was room for real design.

The product was technically interesting. This was around 1990, when DOS was still king. People were starting to sell computers as cash registers to higher end stores. One of the major problems was that the credit authorization services did not yet do any sort of real networking. Everything was dial-up. (And, in fact, networking was only a LAN thing.) This meant that if you wanted the register to do credit authorization itself, then each register had to have its own modem. This was an expense.

The owner of the company had realized that these PC based registers were often networked together. So why not have a modem on one server PC and have the other registers use that? But obviously a dedicated PC was a large expense, so why not have the "server" be a little program that resides on one of the other registers.

Remember, this was the days of DOS. "Little program running in the background" meant a "TSR" or Terminate and Stay Resident program. These were very tricky. It was essentially doing multiprocessing on a single-tasking machine. But I was well equipped for this as I'd spent over a year doing these sorts of programs. The first thing I did was not reinvent the wheel. I'd seen a cheap TSR toolkit that did much of what I wanted, so in pretty short order I had a prototype running. You could hit a hotkey on one machine, enter an amount and a card number, and have it send the request, over a netbios LAN, to another PC which then authorized the transaction in the background and returned the result.

I then turned to the bigger problem which was that every network had its own protocol. Doing what was often done, which was to write new code for every damn protocol, was a maintenance headache. So I created a sort of protocol definition language that allowed you to specify how the protocol worked in a sort of markup language, run that through a "compiler", and load that into the actual program. It made moving to a new protocol very easy. I was very proud of it. The project as a whole was probably the most technically successful program I've ever worked on. It did what it was supposed to, fit in something like 140k of memory (swapped into the area above 640k, with a very small footprint, like 20k, in the lower part of memory) and was pretty easy to maintain.

That was the good. Then there was the bad. I worked in a room in the guy's basement one desk while he did the business stuff from a desk off to the side. Next to him sat his wife, the CFO. That was the whole company. Testing required multiple PCs and he was pretty insistent in helping me test at ever stage of the process. I'm not talking "unit test when I'm ready". I mean, he wanted to be involved every time I ran the program. Now I tend to work in an iterative fashion. I typically throw things together, see how they work, modify it here are there until it is where I want. This means, of course, doing lots of tests where I damn well know it won't work. I'm just checking to see that one particular routine does what I want. But the owner was not a developer, so he never understood this. He took every error (i.e. every time the program didn't do exactly what the specs called for) as an affront and would demand to know why it didn't work. It was painful, especially when dealing with credit authorization networks that often came with incomplete specs where the only way to discover what they did was to try things out.

About half way through the project, he had some sort of heart issue and his wife put him on a macrobiotic diet. She insisted that she feed me lunch as well. So the job came with lunch. If you can call a whole roasted sweet potato and nothing else, not even butter "lunch".

The coding went fast. The business side was...interesting. Sitting six feet from the owner, I got to hear most of it in one-sided phone conversations. A pivotal conversation occurred shortly before my time ended there.

Owner: "Yes. Uh huh. Yes, it does that. Yes, we support $CreditNetwork".
(Author's note: I'd never even heard of $CreditNetwork at that point.)
Owner: "Yes. Yes we support $Feature."
(Author's note: I cannot for the life of me remember what $Feature was. It may have been the extract slack restaurants put on the authorization to account for the tip. Suffice to say that not only did we not support it, but we'd never even talked about it.)
Owner: "Yes. It's installed. This feature is used in over 300 beta test sites."
(Author's note: at this point, no version of the software had ever been run anywhere but the owner's basement, certainly never in a live situation.)
Owner after hanging up: "Ucblockhead, can you implement $Feature?"
Ucblockhead: "Er...I suppose. It shouldn't be to hard."
Owner: "Great! Get started!"

The owner's wife was looking a bit perturbed about all this.

Owner's wife: "I really don't think you should be lying to people."
Owner: "Oh, don't worry about it. It's just the way business is done. Right, ucblockhead?"
Ucblockhead: "Er...uh...no. No, actually, it isn't"

An icy silence descended.

I continued working there for roughly a week. Then, one day, I got a call from the owner. "Hi. I decided we needed a code audit. I called in someone to look at the code. We won't need you until he's done.

A couple days later, I was told my services were no longer needed. This was fine by me. I had been hunting for something new for a couple months at that point and thought I was close to another offer. (And, indeed, I got one a couple weeks later.) But the story doesn't end there.

A couple weeks later, I got a call from the owner's wife. She said that the software auditor, who had now replaced me, had some questions, and ask if I would meet with him for an hour or so walk him through some things. Mostly out of curiosity, I agreed. I mostly wanted to know what was wrong with my code.

The guy came over to my house and I started walking him through my code. It was a very confusing conversation. First, he didn't seem to understand the basics of what was going on in the code. Was my code really that unclear? But then he started saying things like "Oh, that's really cool!" and "That's kinda slick!" I was confused...this was the guy who got me fired? Then, as he was about to leave, he said "Well, that's a really nice system. I hope we can work together some time."

That's when it hit me. He'd never reviewed my code. He had no clue why I'd left.

A couple weeks later, I got a legalistic letter from the owner's wife in her capacity as CFO. It warned me that my meeting with the new programmer should not be construed as fulfilling all my obligations and that of course I was legally bound to fix all bugs and/or defects in my code free of charge for as long as the software was in use.

I was floored. Then I laughed. Then I wrote a long note informing her that I charge an hourly rate for all work, and that I was under no obligation to fix any bugs in code I'd been forced to abandon without warning, whether free or for pay, and that if I did, in the future, elect to give them any help, it was entirely because I'm a nice enough guy to want to help whatever new guy they brought in. I then suggested that she read up on employment law.

There was no response.

An acquaintance of mine ended up doing a little bit of coding for them a few months later and so I got to learn the ultimate fate of the company. The software got done, but they still hadn't managed to sell it yet. Then the CFO gave the owner divorce papers. The company apparently did not outlast the marriage. I believe it lasted about a year from inception to destruction. I was there about six months.