Nothing but icing

posted: November 10, 2017

tl;dr: I am fully enjoying focusing entirely on software and letting others handle the hardware headaches...

I’ve been at Uprising Technology for a little over two years, and I am still having a blast. I joined the company for several reasons: the people, a product I could believe in, the cloud technology, and a re-entry into the startup scene after years working at larger, public technology companies.

One other reason was the desire to, hopefully once and for all in my career, say goodbye to hardware and focus entirely on software. Most of the products I’ve developed in my career have had both a hardware component and a (much-larger) software component. I have worked on some pure software products, such as management systems and various applications going all the way back to the pre-Windows era, when you had to switch the monitor from text mode to graphics mode to display any sort of picture or graph. When developing a product with both hardware and software, I always considered the hardware to be the cake: the necessary underlying infrastructure to provide support and conveyance; and the software to be the icing, which is what people (customers) really care about. Now that I am doing 100% software only, it truly does feel to me like I am eating nothing but icing - meaning I’m having a blast.

Many people do not understand how little hardware development is actually done at what they view as a hardware company. It really does not take that many hardware engineers to design a printed circuit board to hook some chips together, typically a processor, some memory, and some specialized input/output (I/O) chips. The I/O chips are usually the fundamental reason why the board needs to be designed in the first place and cannot just be purchased off-the-shelf from a computer systems vendor. The ideal number of hardware designers for a board is one. A larger system with multiple boards will need multiple hardware engineers, along with a packaging (typically mechanical) engineer.

Each board will need software on it to do anything useful. Then, in a multi-board system, there’s system level software to integrate the functionality of each board into a coherent device or system. There’s a user interface to allow the device or system to be controlled and operated. Then there’s management software to manage collections of these devices and systems, as they will no doubt be networked together. Finally, there’s a need for another whole user interface at the network layer, so that network operators can manage large networks of these devices and systems. Think of the Johnson Space Center Mission Control Center for this layer. Although I’ve not developed any software directly for NASA, I have developed software for similar control centers while working at what some people would call a hardware company.

Johnson Space Center Mission Control Center

Software also is where the intelligence of the system resides, and much of the product’s differentiation. It is incredibly hard to sustain an advantage in hardware performance because it is so easy for board-level hardware to be both copied and surpassed when newer, better chips appear. China has huge manufacturing companies with large teams of engineers who can reverse engineer any non-chip-level hardware product and produce knockoffs (or even something better) in a few weeks. It is much harder for any company to duplicate good software.

So even in a hardware company (is Apple a hardware company?) there will typically be many more software developers than hardware designers. In my career at such companies I probably spent about 80% - 90% of my product development time working on software, which is also about the percentage of software engineers among all the design engineers. Yet getting rid of that last 10% - 20% of my time that I had to spend on hardware issues has been so liberating. Modern-day software consists of layers upon layers of code. At the very bottom, of course, there has to be a hardware layer with a CPU executing instructions by turning transistors on-and-off extremely rapidly. A true “full stack” developer would, I suppose, know the entire stack all the way down to the assembly language in the server’s operating system. But it is not possible to be an expert in all layers. I don’t have to worry much about the hardware layer; our cloud vendors do that for us.

The icing tastes great.