Code is Part of the Machine

I intend to share with you a realization that recently crystallized around discussions related to software complexity and stack comparisons.

Computers are very complex lately. They have multiple processors with multiple cores each, communicating with each other to let you wait for idle seconds while that spreadsheet software opens. Or while the kitty “gifs” (likely rebranded mp4’s) load.

Processors can also have microcode, and on top of them sits an operating system, on top of which is our stack, on top of which is our code.

Computers, with all their hardware and software, are machines that imitate other machines – often better than those that inspired them. For instance, almost any text editor in use today we can think of as an impossibly powerful typewriter.

The code we write, and the code we build upon, are part of the machine we are putting together. Yet this is one of the aspects that need to be taken into account when building stuff for the long run: the amount of code present in your production machines is part of the machine.

Complex machines are harder to reason about, keep running, and upgrade than simpler ones.

There are other things to consider, of course, but with the simple comparisons out there of how different programming languages can be more or less complex I think we need to separate things and think about each aspect individually.

Even though this

print("Hello, World")

is easier to read than this

#include <stdlib.h>

int main(int argc, char* argv[]){
    printf("Hello, World");
    return 0;

All else being equal, the latter is by far the simpler machine.

I’m not certain whether I’ll get to develop this idea as much as I want to in the future, or write about other aspects that need to be considered when you’re building long term systems, so here are some related thoughts:

  • All the code in the production computer, no matter where it comes from, is part of the machine you’re building.
  • All production computers that interact in order to make the system you’re building work are part of the same machine.
  • Yes, this includes the client’s computer, and the client’s phone, with all the apps that are running in the device.
  • Routers and switches are computers.
  • Now that I reflect upon it, I think this is something that Microsoft has known for ages, and part of the reason stuff running on MS systems keep working for relative aeons through upgrades. Some of Raymond Chen’s blog, The Old New Thing has convinced me of that.
  • Ease of writing code doesn’t mean ease of maintaining code doesn’t imply ease of running the code.
  • The most valuable thing to come out of DevOps is the very sane notion that the development team should be involved in making sure the system keeps chugging along.
  • Considering the way early digital computers worked and were programmed, thinking about modern computers as “machines that rewire themselves continuously on the fly” becomes very attractive.
  • The total number of possible machines your production computer can become is part of the complexity of your setup, and is a corollary of the idea that code is part of the machine.
  • Whether your dependencies will become updated or not, the interfaces you depend on die or not, or there are vulnerabilities in your code are a different issue.
  • Sometimes we come close to acknowledging that code is part of the machine. In those instances, we call what we’re building a “platform”.

If we’re going to reason about all this, it’s important to not muddle our thought process and address as much or as little of the environment of building and running applications as we really mean to.

There is more where that came from, but I don’t know that I’ll have the tools to write it properly. So there we go, I hope this tickles your mind and gives you a new way to think about software systems.