I was having a conversation recently with someone and we got onto the topic of how someone who’s smart and good at building things in software isn’t necessarily good at making or fixing hardware (by which I mean anything physical, including home improvements etc). I’m one of these people. It seems like many of the skills should be the same: the ability to visualise the desired end result, putting smaller pieces together to make the whole, the curiosity and intelligence to figure out how things work, the patience and concentration required to complete the job. But they are still different skills and both require different types of practice to get good at them.

Generally I believe that anyone can learn any skill if they’re prepared to practice. However there are many aspects of working with real physical things that I just plain don’t like and, when compared to software, annoy me too much. So I’ve never really been motivated to practice and get good at them.

No Test Environment

When fixing something that already exists, you only have that one broken item to work on. For example, I have a tap in my kitchen that really needs some work. I either need to replace it completely, or else remove it, take it to bits, give it a thorough clean and descale, probably put new washers in, and put it all back together again. This is risky because I’ve never done this before. I’m going to have to turn the water off to do this. What if I never get the tap reinstalled properly? I won’t be able to turn the water back on!

If this were a software tap, I could take a copy of it and work on the copy, leaving the original ‘live’ tap in place working as it does now. I could do it wrong as many times as I like until I hit upon the right way to do it, then keep just the copy that works.

If I’m building something new, this isn’t such a problem. I can make as many terrible coffee tables as I like without too much risk (other than that my apartment will fill up with bad coffee tables).

A related benefit of software is that I can refer to the old copy when building the new copy. Once I’ve taken my physical tap apart, I have to hope that I can reassemble it in the right way from memory. If my new software tap isn’t quite right, I can refer back to the old copy to see how it used to work and where I might have gone wrong.

Tools

While fixing my tap I discover that I need a tool that I don’t have. Perhaps there is some funny type of screw I need to undo and I don’t have the right screwdriver. I’ve got to go out and buy a new tool. If it’s not available nearby I might have to order it. Such a tool might not even be available at all. All the while, my water is off! In software, if I don’t have the right tool (and there isn’t one available on the internet), I can probably build it myself. The programming language I’m using to fix the problem can be used to make the tools to help me fix the problem! In fact, the difference between tool and solution gets pretty blurry; it’s all just software.

Space and Materials

I’m going to need some physical space to lay out all my tools and bits of tap. I might not need much space for a simple tap, but if I were building a coffee table, I’d need lots of space. Software basically just requires space for me to put a laptop. (And two monitors, keyboard, mouse etc!). And the physical space required isn’t dependent on how big the thing I’m making is (except for the amount of disk space and memory it takes up).

To build my coffee table I’m also going to need materials. The more terrible coffee tables I make, the more wood I’m going to need. I’m not sure what the software equivalent is; perhaps data for my program to operate on? Data is just software too, and I can write a tool to generate data. And large amounts of data don’t take up any more space.

Documented Interfaces

I take my tap to bits and discover that one of the fastening bolts is rusted through. I can remove it but now I need a replacement that’s exactly the same as the old one. The bolt doesn’t say on it what kind of bolt it is. I might be able to measure some properties of the bolt, like the length and diameter. But it’s basically a visual task to find a matching bolt. Off I go to the DIY store with my bolt and search through all the available bolts in the store.

With software, interfaces are discoverable and (usually) documented. I can find out exactly what the inputs and outputs of a function need to be, or what format my data needs to be in.

Adapters

I can’t find the right kind of bolt. I could buy the closest similar bolt but it’s going to be either too large or two small for the hole, so I’m basically stuck now, unless I either manufacture my own bolt to the required specification, or buy a new tap.

In software, if I’m trying to fit two incompatible components together, I can write my own translation layer or adapter which allows them to work together. This makes the solution slightly more complicated than it would have been otherwise, but solves the problem.

Decay

After much struggle and hassle, I eventually fix my tap. After several years though, it starts to rust again, limescale builds up and I need to fix it again.

Does software decay too? Mainly it depends on what external libraries and tools you’ve referenced. It’s perfectly possible for a simple, stand-alone program to keep working through many hardware and OS upgrades and other changes. But software that’s built for a particular OS is obviously going to stop working if that OS changes.