One of my biggest frustrations working as a software developer on Tandem machines revolved around the difficulties I encountered with the Tandem text editor. Tandem terminals were block-mode devices rather than character mode. This meant that the terminal would accumulate a string of characters in its local memory and then send a block of data back to the computer and wait for it to refresh the entire screen. This architecture was quite efficient for transaction processing applications where fields of data are entered using screen templates; however it is not very efficient for simple text editing. Every time I would press a function key to send data to the computer, I would experience a pause of indeterminate length. Sometimes the computer would respond immediately, but most of the time the response delay was longer than a second or two. The impact of this on my concentration was disastrous because every time I had to wait, my mental cache would drain into the bit-bucket in the sky.
When micro-computers came along, the response they gave was always instantaneous. From this experience, I formed a principle: editing requires a dedicated computer.
I purchased an Apple ][ in 1979 or 1980. Initially I used it to track personal finances. Several applications emerged pretty quickly but they didn’t have very good printing capabilities and I could not export the data from them to other applications. I played briefly with UCSD Pascal but it ran out of memory very quickly. So for the most part, the Apple ][ appeared to be little better than a game machine until the appearance of…
VisiCalc – the First Killer App
When I discovered VisiCalc in 1980, I realized that a single application could easily justify the purchase cost of the entire computer. Written by Dan Bricklin, VisiCalc introduced the concept of a spreadsheet on a microprocessor and was an instant hit. After porting VisiCalc to a number of emerging microprocessors like the Commodore PET and the TRS-80, VisiCalc was ported to the IBM PC and became one of the initial pieces of software+ available for its 1981 launch.
I purchased an IBM PC shortly after its initial offering. At last, I owned a computer that I didn’t have to share with anybody else. But how do I hook up my PC with the Tandem computer? Fortunately, the Tandem terminals use a serial connection and the IBM PC had a serial port, so that seemed the logical place to begin. All I needed to do was to write enough code to ship text back and forth between my PC and the Tandem mainframe and voila! Problem solved!
IBM PC Technical Reference Manual
I started by devouring the IBM PC Technical Reference manual. I studied the BIOS and read the code line by line. I figured out how to write an ASYNC COM Port driver and that became my first piece of working code for the PC.
Now I needed some code that would allow me to build an editor. In reading the BIOS, I realized that there were two ways to write to the screen: I could feed each character (byte) to a bios call that would write it on the screen, OR I could write directly into a 25×80 array of memory that was mapped directly to the “Green Screen”. The first approach was painfully slow, but the second approach was blindingly fast. As I dove into this approach, I discovered that I could build a large (64KB) array of memory and selectively copy portions of that memory onto the physical screen’s memory. I could build a windowing system.
I worked on this code obsessively until I had a real product. Donna and I started a company called Amber Systems. The name “Amber” came from a series of Science Fiction books by Roger Zelazny. We enjoyed these books so much that we gave our second son the name “Corwin” after one of the main characters in Zelazny’s books.
Amber Systems, in the best traditions of Silicon Valley started in our garage. 1883 we presented Virtual Screen Interface (VSI) at the West Coast Computer Fair. We had created a manual, a quick reference card (patterned after the IBM 360 Reference Card). We had a demo and we sold several copies at $295 each. VSI was written up in InfoWorld in November, 1983 and we did a licensing deal with Lattice who sold it under the name “Lattice Windows”.
I was (and still am) quite proud of VSI. It was about 10K of assembler and had interfaces to C, COBOL, FORTRAN and several other languages and ports to several other machines like the WANG PC. VSI was capable of displaying as many as 255 overlapping windows and it was blindingly fast, but it only worked in character mode. It had no support for graphics. This was OK for the early days of the IBM PC, but eventually Microsoft figured out how to make Windows work and the character mode code was relegated to the dustbins of the past.
During the next few years, VSI became a critical component of several other products, the most significant of which was HomeBase, released in 1985. Homebase was a “Terminate & Stay Resident (TSR) program that had many advanced capabilities for its time. It had a Notebase, background file transfer, calendar and a structured search capability.
Homebase was developed by a core team of less than half a dozen developers spread all over the San Francisco Bay area. We shipped files back and forth and battled with Alex Morton, our marketing guru who wanted to release the software before it was ready. Alex and I can laugh at our battles now, but I learned an important lesson during this process: announcing a product before it is ready can lead to disaster.
We also used VSI as a component of two products Frank Frazier (a friend from Tandem) and I developed for J.K. Lasser in 1985. “Your Income Tax” and “Your Money Manager” were both written in C. VSI made them a lot easier to write.
Strangely, a few years ago I was asked to make a deposition in a big lawsuit between players I cannot name that involved VSI and its interaction with the mouse. I never learned the outcome of the lawsuit and I am still curious about it. The lawyers spent a lot of money to fly to Bellingham and grill me for two days, but I got a few bucks for my time, so I cannot complain.
Amber Systems ran out of money and went on the rocks shortly after that. Alex Morton sold our code to Brown Bag Software, but I never got a piece of that.
Lesson Learned: If I want to make money writing software, make sure I maintain ownership rights to my code and have a good lawyer.
Micro Machines Raster Image Processor
After leaving Amber System, I took a job as a development lead at a Silicon Valley company called Plexus that made UNIX systems. They had a vision of front-ending their UNIX box with a PC and equipping the PC with a Raster Image Processing (RIP) scanner board that could scan documents at high speed and then store these as BLOBS (Binary Large Objects) in a modified version of Informix. Steve Jones was leading the modifications to Informix, Mauritzio (I’ve lost his last name) led the PC development using Windows 2 while I led the integration of the RIP board with the optical disks on the server that would capture the images.
The RIP board had an on-board Texas Instruments chip that controlled the scanner with software written in C, but the C was written by the hardware engineer who designed the board, and clean programming was not his strong suit. It took me awhile, but I finally understood his code and wound up rewriting most of it. This turned out to be a very fortunate experience because I got sideways with the Engineering Manager. I wouldn’t attend his prayer circles so he gave me a bogus review and fired me.
The day I got fired I had been playing volley ball with some of the other engineers and landed sideways on my foot and broke my ankle. I went home that day with a cast on my foot and a pink slip in my hand. Not the best news for Donna, but we turned it around. I got a handicap pass from the doctor and turned that into a nice blue notice I could put in my car window and then we took our three children to the 20th Anniversary of the Summer of Love in Calaveras County, CA.
For the next three days, we lay on the grass and blissed out to Santana, The Grateful Dead and many others. Our son Corey found a squirt bottle and had way too much fun making sure that the concert goers were kept cool while our daughter, Lisa found yet another friend.
I learned several lessons from this experience:
- Getting fired may be a good thing.
- The Universe demonstrated once again that it will take care of me.
- A broken ankle can have a pretty cool upside!
During my Amber System days, I learned that there was an adult soccer league in San Jose. I never played soccer as a youth so there was no way I could handle a ball like these guys could, but as an ex-football tackle, I understood how to charge and block. And as a big bear of a man, I instinctively understood that the goal cage was my cave. Enter at your peril. It may not have been entirely legal, but I developed a mean slide tackle and didn’t hesitate to take attacking players out. I had three encounters with a particularly aggressive forward. The first time he tried to out jump my hands. He lost. The second time he kicked me in the face. The third time I trapped his leg as he tried again to kick me in the face. I busted his ankle. Hope he got good use from the handicap sticker I am sure he needed for many months after that encounter.
Two of the players on my team happened to work at Ford Aerospace in Palo Alto. When I lost the job at Plexus they got me an interview at Ford Aerospace and one of them, Dave Ward became my manager. Dave was a quiet and highly competent manager and helped me get promoted quickly so that we both reported to Jan McCleery who was the best manager I ever had the privilege of working for.
Even though most of my friends thought the Ford bureaucracy would drive me nuts, Jan taught me to work the system. She had me walk through each process I would need and meet all the people who handled those processes. She taught me to make relationships with them so that when I needed their help, I wouldn’t be just a name on a purchase order request.
With Jan’s help, I became a supervisor in a newly emerging team that had as its mission creating a standard software development infrastructure that could be used by all of the engineering divisions throughout Ford Aerospace. I learned about many SDLCs such as DoD 2167A, otherwise known as the Waterfall model and its many variations.
As we focused in on more iterative models, it became time to order a bunch of equipment. With the skills Jan had taught me, I purchased about 15 SUN Sparc workstations and a large SUN Sparc server. When the equipment arrived, I was like a kid in a candy shop. I worked with the SUN engineers and our own Systems Administrators to unpack and set up the gear.
“Don’t hook anything up to the network,” said Charles Brooks, our lead SysAdmin as we finished for the day. I heard him, but I was on a roll and I wanted to see these puppies in action. I turned my machine on and plugged in the LAN connection and a message popped up saying “Invalid subnet mask.” It registered that there must be a small configuration problem, but I pressed onward and connected my machine to our server.
First thing the next morning, Charles appeared in my office and asked me, “Do you know what a subnet mask is?” I confessed ignorance and a part of me started to feel like I had been caught with my hand in the cookie jar. Charles patiently explained that a subnet mask limited broadcast messages to a specific subset of IP addresses. It turns out that the subnet mask on my machine allowed messages to go to lots of machines that should not have seen it. The message they got told them to mount a portion of their directory structure on an unreachable address. About half the machines that received this message had been upgraded with a bug fix and they (wisely) ignored my broadcast message. The other half of the machines on our network had not yet been upgraded and they tried to execute the mount request. Over 500 UNIX machines wound up hung and needing a hard reboot. The machines did not like to do a hard boot and neither did their users. I was not a popular guy that day, but I did learn another lesson or two:
- When your Sys Admin tells you not to put things on the net, he has a reason. Listen to him.
- Networks are complex critters. Don’t mess with them unless you know what you are doing.