|
|
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.
Imagine an image of the Liquid Crystal Display of this watch taking up a PC screen or window - that's what the simulator did
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 was not too many years removed from college, where one of my favorite class projects had been writing a simulator of the DEC PDP-8 on an IBM 370. A simulator takes the machine instructions intended for one CPU and does the necessary operations to be able to execute them on the second CPU and produce exactly the same results in memory of the second computer, in a virtual model of the first computer. If the second CPU is more powerful than the first CPU, it’s actually not that hard a task, and the resulting simulator can even run as fast or faster than the speed of the first computer. This is the same basic process followed today by many languages such as Python and JavaScript, which compile down to their own individual assembly languages or bytecodes or instruction sets, and which then rely upon a Low Level Virtual Machine (LLVM) to do the final translation to the machine code of the CPU that is actually running the 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.