posted: April 22, 2023
tl;dr: Amazing things can sometimes result when software developers are allowed to work on whatever they please...
Google co-founders Larry Page and Sergey Brin famously used to "encourage…employees, in addition to their regular projects, to spend 20 percent of their time working on what they think will most benefit Google." I have no idea whether that policy or aspect of the culture is still in place, especially now, as Google and other large technology companies that grew rapidly during the pandemic reduce staff in its aftermath. I have, however, experienced the benefits that can result when software developers, completely of their own volition, work on side projects that turn into valuable products or tools that deliver unexpected benefits to the company.
One example is of my own doing. I was early in my career, working as an engineer at smartwatch start-up company AT&E Laboratories in the 1990 timeframe. I had recently moved myself to Oregon and hadn’t yet established much of a social network. The work they assigned me didn’t overload me, so I had plenty of free time in the evenings and on weekends. I was intrigued by a problem that I saw at work.
The microprocessor for the smartwatch that I and the rest of the engineers were working on was going to use a brand new Seiko CPU. The CPU was being developed in parallel with all the other major components of the smartwatch, including the software. Believe it or not it was a nibble (4-bit) processor, which operated upon 4-bit “words” at a time. While woefully underpowered in comparison to even the third-generation Intel 386-based personal computers of the time, it was sufficient for a digital watch, which mainly just has to store a small number of digits in the range of 0 to 9 (which fit in 4 bits) to represent the time of day, the date, and perhaps a stopwatch timer. The new CPU from Seiko was going to be souped-up to run at a clock speed of 50,000Hz or 50KHz, an increase from the 32,768Hz speed used in other Seiko digital watch CPUs. The overarching design goal was to keep time while consuming the bare minimum amount of battery power.
I and a few other engineers were writing software, in assembly language, for this under-development chip. The instruction set was known and the assembler (to turn the assembly language into machine instructions) existed. But we wouldn’t have anywhere to run our software until the first prototype CPU chips were done and they were placed into a larger board design called an ICE, for In-Circuit Emulator. The ICE was basically a computer containing the CPU that allowed us to load our code into it, hook it up to other peripherals, run it, set breakpoints, and examine what was happening. Until the CPU and ICE existed, we were blindly developing software.
I decided to write a simulator for the forthcoming Seiko CPU. I did it on my IBM PC clone using the C language to mimic the Seiko chip’s instruction set. When I realized that, in order to be useful, I needed to simulate the smartwatch display, I moved to C++ so that I could draw a large representation of the watch display on the PC’s screen. Given the timeframe, this must have been a Windows 3.0 application. I quickly realized that, in order to be even more useful, I needed to write simulators for the other peripherals on the smartwatch, such as the packet networking interface that allowed the smartwatch to receive messages. When I had the simulator working well enough to run our actual watch code and display the time-of-day it was keeping on the PC screen, I showed it to my boss.
He was blown away, as I hadn’t said a word about what I was working on in my spare time. He immediately grasped the benefit to the entire software team of being able to run our code on the simulator while we waited for the new CPU and ICE to show up (they ended up being delayed, naturally). He turned my skunkworks project into a real project, and assigned another, more seasoned, software developer to flesh out my simulator by adding code to simulate the other watch peripherals. While I was a bit sad to see someone else take over my baby, I learned a lot from the more senior software developer, and together we refined it into a useful tool. It pleased me to see the other developers on the team using it and saying nice things about it, and thanking me for having the initiative to develop the initial version.