After receiving my Ph.D. in 1970, I left academe, and directed software development for five years for a company called Micronetic Systems. They made a minicomputer-controlled machine that used a Neodymium-doped YAG laser to trim thick-film resistors on ceramic circuits. That was my first experience with a small entrepreneurial start-up, although I was just an employee, not a founder.

I next did some rather sophisticated hardware development of Statistical Multiplexers for the modem-maker "Codex". Yes, I switched from managing software to digital hardware design! Remember, I'm an Electrical Engineer.

Mid 1978, for various reasons, I was thinking of making another career move. I purchased a book by Bernard Haldane entitled, "Career Satisfaction And Success". Haldane suggests basing your career on things that you enjoy doing, and do well - what he calls "motivated skills". He proposes various exercises in which you look back over your personal history, and identify things at which you succeeded, and which you enjoyed doing. You then try to distill the particular skills which were involved, and attempt to identify a job that would use them.

This exercise revealed to me that I had enjoyed my time at Micronetic Systems more than I had enjoyed my much more technically challenging work at Codex. I found that I had gotten a great deal of satisfaction out of being a big fish in a small pond. I enjoy pulling rabbits out of hats; that is, being a hero in emergencies. I enjoy being a problem solver, and working against a deadline. Maybe that's why I did well at MIT.

Clearly, from a purely career-oriented point of view, the time had come for me to be one of the founders of an entrepreneurial venture. However, there was a trade-off to be made. My first daughter had not been born until I was 33. My second daughter had been born in May of 1978, so I now had two daughters, aged three and less than a year. Working for a startup would have me working 80 plus hours a week, probably for years, and I would miss a lot of my daughters' growing up.

I made this trade-off in the direction of family, and decided not to get involved with a raw startup. I set out to find a young, entrepreneurial company, but one a bit further along in its development. I wanted a company young enough to feel exciting and dynamic, but past the 80 hour a week "garage" stage. I wanted a company young enough to grant me some significant stock options, but I was willing to forgo the really large share of the company that comes with being a founder. I was still young enough to take the risk that a new company might not succeed. After a long search, in early 1979 I located the startup company Kronos, through a letter they had posted at MIT's Alumni Placement Office.

The Kronos product was a timeclock, such as might be used by factory workers to record their work time. In 1979, timeclocks were basically mechanical time stamps. Kronos's innovation was to apply the newly emerging microprocessor technology to essentially put a computer inside the clock, allowing it to apply work rules consistently and fairly, eliminate errors, total the timecards, and automatically report the time worked to the payroll system.

At the end of two years of development, their timeclock seemed to be working pretty well, and Kronos had started to place it in a few beta test sites. The unit identified the employee associated with each Manila tag timecard by means of a mark-sense grid at the bottom of each employee's timecard, which was filled in by blackening squares with a dark marker. Once the employee was identified, the timeclock recovered that employee's punch history from memory. The clock thus knew how many lines had already been printed on the card, and hence where the next line ought to go.

The software kept track of the position of the card being inserted by watching a set of black marks in a "clock track" printed along the left edge of the card. When the card reached the proper line on which to print, a high-speed clamp stopped the card's motion. The clock then printed the employee's timestamp on the card, before releasing the clamp. If the punch was an OUT punch, the employee's updated totals for the day so far were also printed.

There was one small problem, but it was highly intermittent. Every now and then, rarely, and completely unpredictably, when the high-speed clamp stopped the card, the microprocessor would go out to lunch. The clock would stop functioning, with the clamp engaged. Since the electromagnet of the clamp was heavily driven to cause it to close very rapidly, when it was not released in a timely fashion, it would start to heat up, and eventually it would smoke and burn out. The intermittent nature of this problem made it extremely hard to track down, and no one could figure out what was going on. Obviously, the product in this state was not acceptable. It was designed to hang on the wall and run for years with no service calls required. Of course, the hardware people said it was a software problem, and the software people said it was a hardware problem.

One of the founders, Larry Baxter, the engineer who was the main designer of the hardware, wanted to become less involved with the company. A master at low cost design using microprocessors, he didn't want to hang around and manage engineering. So Kronos went looking for someone who could both fill his position in the long term, and also, in the short term, resolve the problem of the smoking solenoid. They needed a talented engineer familiar with both hardware and software. They needed ... me. After an extensive interview process, I was offered the job of Chief Engineer.

Of course, I quickly looked at their intermittent lockup problem. It sure looked like a hardware problem, especially since it always occurred just as the high-energy card-clamp solenoid was energized. Obviously, the first thing that an Engineer would suspect was that the microprocessor was being derailed by an induced voltage spike. But the solenoid had its own separate power supply and ground path, and a study of the hardware in operation showed that energizing the solenoid didn't product a noticeable glitch in the microprocessor's power.

I investigated the hardware first only partly because it seemed to be the most likely culprit. I was also getting little cooperation from the software people. The primary programmer, a co-op student, resented the fact that I had been brought in and that he would be reporting to me. He gave me no help in trying to understand the software, page after page of assembly language code with hardly any comments. There was no design documentation. There was only one top-level flowchart, but it looked like spaghetti.

Finally, I plowed into the software on my own. I simply read the assembly language code, not an easy task (especially without comments). I discovered that the spaghetti-like flowchart was an accurate rendition of the state of the software. It was a mess, and so badly written that I got to a point where I could flip open the fat listing to a random page, read down a few lines, and come up with a bug. Once I started reading the program, it took only a short while to trace the intermittent lockup problem to the software, to a very badly designed interrupt system, thereby saving Kronos's corporate ass, if corporations can be said to have an ass.

The co-op student who had written the bulk of the code was a speedy, prolific programmer. But he derived some of his speed from writing no documentation and omitting comments. He also coded first and thought second, if at all, and it's said that, "The sooner you start coding, the longer it will take you to finish". ^Note 1  The co-op student also didn't know what he didn't know, and, it turned out, he didn't know how to design an interrupt system. The system was not crashing when the solenoid clamped due to a glitch on the power lines. It was crashing at that point because the printer operation was starting up, and a lot of software "interrupts" were occurring.

Mitch Radcliffe once said, "Computers let you make more mistakes, and faster, than anything except handguns and tequila." We had to almost completely re-write the clock software. It was tough going for a while, with long hours. I lost some hair, and got beaten down a bit, so I'm no longer tall, dark, and handsome (but two out of three isn't bad ^{Note 2}). After the re-write, the lockup problem disappeared completely, and I was promoted to Vice President - Engineering.

How did I feel my job search had worked out? After all, during the software rewrite, the three-person team I put together (including me) ended up working the 80 hour weeks that I had wanted to avoid. It had turned out that the product was not as ready to sell as Kronos had thought, although the misrepresentation was not deliberate.

But, in fact, I was ecstatic with my choice of Kronos. It gave me exactly what I wanted in a company: a small, dynamic startup, in which I could be a big fish in a little pond. It gave me a chance to come in, be a hero, and save the company from destruction, and I was amply rewarded for my efforts. I had no objection whatever to working 80 hour weeks for three months. Three months is nothing -- at Micronetic Systems, I worked 80 hour weeks for three years. 80 hour weeks for three months at Kronos was a hiccup. That will happen from time to time in any small company, and in most large companies as well.

Later in 1979, the first batch of production timeclocks was loaded into a station wagon, to be driven to New York City for delivery to our exclusive dealer, Interboro Time. A photo of that event is shown below. It contains almost all of Kronos's employees at the time, except for Aron Ain, who was already in New York, preparing for the product's arrival.

Note 1:   I first came across this adage in an electronic "signature" from Chris Hines. Trying to track it down, I found a web site that attributes it to Roy Carlson, in More Programming Pearls: Confessions of a Coder. But I'm not really sure where it originated.   [return to text]

Note 2:   Which two? Well, my height is 1.65 meters (5 feet 5 inches).  [return to text]