On The Merits of Using Standard Parts

When I was much younger I had a european car. Not a fancy, nice, european car, but something that was just…“unusual”. One day the alternator in the car stopped working, and I needed a new one in order for my car to work again. The man from the auto-club shook his head, nodded sagaciously and said that if my car had been a Toyota, Ford or several other more popular brands I could be on my way for a few hundred dollars, because he carried alternators for those makes of cars in the back of his truck. Instead I was left with the option for a reconditioned alternator, which had to be sourced from out-of-state for over $1000, or pay $3000 for a brand-new alternator that would take a few weeks to arrive. An alternator is basically an electric motor driven backwards. Instead of current producing rotation, rotation is used to produce current. You could probably make a simple alternator if necessary from magnets and copper wire. And yet there I was, paying thousands of dollars and/or waiting weeks for a ‘special’ alternator.

A metal shelf I had a related but opposite experience making a utilitarian metal shelf like the one shown in the image above from a flat-pack kit. The kit had 3 kinds of parts. Screws, slotted aluminium “angle” for legs/verticals, and rectangular metal shelves. All the parts of each kind were identical. They didn’t have a particular orientation so you couldn’t put them in backwards or upside down. They were totally interchangeable. Not all my flat-pack experiences have been so pleasant. I’m sure I’m not the only person who has partly put something together only to discover that a particular part can be oriented one of two ways, one of which is “right” and the other is the way I happen to have chosen. Someone even made a game about the process. The best designs seem to use parts with no particular orientation (like my utilitarian metal shelf) or which make it impossible to orient pieces in the wrong way, and where one part can’t be mistaken for another.

You can do a lot with standard components. In its early years Google built highly redundant server infrastructure using commodity hardware. In 2014 Google bought Skybox - a startup that built and launched CubeSats - satellites built from off-the-shelf electronic components. They now own and operate a constellation of earth observation satellites capable of sub-meter resolution, with the stated goal of providing high-resolution imagery of any place on earth multiple times per day.

an Allen Key

There is a lot to be said for using standard components, tools and technologies when building something in software too. New team members have a better chance of being familiar with them. The documentation is better. The edge-cases have been ironed out. Their strengths and weaknesses are better understood. Also if you use the same small set of trusted components within your system your team wont’ be scratching their head trying to decide which of the 3 rules engines in the system they should use to solve this problem (yes, I’ve worked on systems with multiple embedded rules engines). If all of the things doing similar functions work the same way the risk of someone “using it wrong” - the software equivalent of getting half-way through assembling the flat-pack drawers only to find you put one critical part in backwards - will be greatly reduced.

a chair put together badly

“Wait” I hear you say “aren’t you just advocating a lot of boring old stuff?” In my view there is a strong case to be made for boring. There are lots of big companies, large sites and well-known and well-regarded code-bases that use boring technology. Wikipedia is one of the most popular websites in the world. It runs on PHP and MySQL. The same goes for Facebook. The back-end of messaging application Slack is also written in PHP. Popular question-and-answer site StackOverflow ran for many years on a few SQL Server database servers and about 10 ASP.NET web servers. All of these sites have a few more esoteric parts for search or for load balancing, but at their core they’re pretty standard tech. SQLite, the most widely-used database engine in the world, is written in C. So is the linux kernel. Windows is mostly all C++, with the kernel written in C. OSX is written in Objective-C with a C kernel, as is iOS. Google’s Chrome browser is written in C++. None of these languages are particularly new.

One interesting model for thinking about this is proposed by Dan McKinley who was instrumental in building the technology at Etsy over 7 years. In his blog post Choose Boring Technology Dan suggests that companies have 3 “innovation tokens” to spend (and if the company become wildly successful they might get a few more, much further down the track). Each time you go with something relatively unproven, you spend one of those tokens. The great thing about boring things, as Dan points out, is that their capabilities and their failure modes are well understood.

Former Parse and Facebook Engineer, and now startup CEO Charity Majors puts it slightly differently when she says: “if you have hard/interesting problems, solving them will not be cheap or easy, ever.” The best way to do this is not to have them in the first place, and one way to do that is to not create any for yourself by using things that are unproven.

More like this - in a book!

The world is filled with an overwhelming number of new things about software development that you could be learning. I’m co-writing a book called Evergreen Skills for Software Developers to help developers decide what skills are worth learning. Enter your details below If you want to be notified when the book is ready.