Bitsas

The British have a term for motorcycles built of parts from different manufacturers. They are called “bitsas”, for “bit of this, bits of that”. The classic example is a 650 Triumph engine in a 500 Norton frame, which works well. Others? Very much less so. Trying a bad choice of components could throw you down the road.

BIOS

When personal computers first came into existence, buyers and builders didn’t want to have to write their own OS, so many used CP/M. Of course, if their machine had different components than CP/M expected, that wouldn’t work.

So in 1974, Gary Kildall wrote CP/M in two parts, the command loader and the “BIOS”, the basic I/O system. The BIOS contained the drivers for the disks, the file systems on them, keyboards, displays and printers, other devices, memory management, interrupt handling, initial program loading, and parts of the error handling.

That’s still a lot, but developers could modify a sample BIOS to work with their particular selection of devices.

It seemed like a good idea at the time

And it was, for a number of years, and on into the first years of MS/DOS, around 1981. DOS adopted the idea of a BIOS, to retain its ability to run on different kinds of hardware, not just IBM-build PCs.

In the seven years between the two, a lot of new and different hardware coma into existence. Which meant a BIOS could end up using one vendor’s disk system and another’s keyboard-and-screen system.
Can you say “combinatorical explosion”?

So each component vendor tries to make their products surprise-free, by writing local firmware that made, for example, a brand X serial chip behave like an older and more popular brand A serial chip.

That took care of one kind of explosion, but ushered in a new explosion of … bugs. If I couldn’t buy a brand A chip and had to switch to a brand X, with new features, I was depending on the brand X microcode to do exactly what the brand A code had done. Of course, that didn’t happen. Brand X usually had improvements, new features and the like, and all of them had different bugs than brand A. If I found a bug, I either needed to get X to fix it, or invent a work-around.

Interactions

That was bad enough, but what if I used a brand B disk and a brand C filesystem? The brand C filesystem had to be able to run on all the available disks, and so needed to be updated each time a new disk came on the market. It had to get all the disk problem fixed by the vendors, or it had to have workarounds. And my BIOS writer still had to do the same as before, fix or work around the bugs in the disk so it could us the raw disk, or example to put a filesystem on it.

And each time the brand C filesystem had a new release, my BIOS writer had to test it to find the new bugs (there always were some) and fix or work around them.

Then the hardware started to improve

I now not only needed to track the changes to the brand C file systems, I had to track all the new features of all my devices, so I could use the newest and fastest. Or at least to get off the oldest before it became unavailable.

And there were more interactions, so that you got a network effect: to get more bugs from an existing codebase, connect the parts in a different way. And have each of the suppliers forbid their customers from helping. And not help competitors. As competition forced prices down, it also forced bugs up.

So what do motorcycles tell us?

Some combinations of components worked. Some very much didn’t.

What did work were Rickman frames: they started with an engine, and then built everything up from there.

There were a few normal parts, like disk brakes, but there was only one default supplier for each, and fairly few models. All carefully chosen by Rickman to work with their frames.
Bombardier took this a bit further: they bought an engine company and built whole machines around them. A small number of interfaces, all visible, and as few sub-suppliers as made sense.

Bitsas in Software are evil

Today we have an insanely complex BIOS replacement, Unified Extensible Firmware Interface (UEFI), that tries to solve the interface-explosion problem by allowing you to plug anything into anything. Which of course, is just a different way to say “interface explosion”, not a solution for it.

IBM’s ancient OSs were available for customers to read, in assembler and PL/S. That means that they could provide non-mysterious bug reports, and often proposed fixes. Modern OSs, like Linux and BSD, come with full source, so you can both diagnose and fix problems.

To build reliable systems, you need discipline. Design your hardware and software together, choose components where your drivers don’t have to go through someone else’s firmware, and most importantly, choose your component suppliers well. Your parts should last, have suppliers who won’t refuse to fix them, and won’t suddenly go out of business.

Just like Rickman and Bombardier did.