Code Simplicity

Software as Knowledge

I don’t often dive deep into the philosophical underpinnings of Code Simplicity, but I’ve been realizing more and more that there are a few philosophical principles behind the writings that would be valuable to share. Also, some of these philosophies haven’t been fully formed until I sat with the work for a long time, applied it in a lot of situations, and talked about it with many people. This one–a theory that I have developed over time about how software can be thought of and worked with in the mind–has sort of been percolating with me for quite a while now. It’s time to get at least least part of it out on “paper,” in a blog post. So here you go:

Software is, fundamentally, a solid object that is made of knowledge. It follows all the rules and laws of knowledge. It behaves exactly as knowledge behaves in just about any given situation, except that it’s in concrete form. For example, when software is complex it tends to be mis-used. When software is wrong (i.e., has a bug), it tends to cause harm or problems. When people don’t understand some code, they tend to alter it incorrectly. One could say these things of knowledge just as one could say them of software. Bad data causes people to misbehave; bad code causes computers to misbehave. I’m not saying that computers and people can be compared–I’m saying that software and knowledge can be.

One wishes to have knowledge in a sensible and logical form. Similarly, one should also desire to have software–particularly the code–in a sensible and logical form. Because code is knowledge, it should translate to knowledge in one’s mind almost immediately upon viewing it. If it doesn’t, then some part of it is too complex–perhaps the underlying programming language or systems, but more likely the structure of the code as created by its designer.

When we desire knowledge, there are numerous ways to acquire it. One could read about it, think about it, perform observations, do experiments, talk about it, etc. In general, we could divide these methods into acquiring the data for ourselves (via observation, experiment, thought, etc.) or getting data from somebody else (reading, talking, etc.).

There are some situations in which we must get data for ourselves, particularly when it applies to us in some unique way that we couldn’t rely on others to work out correctly. As an extreme example, walking on my own legs likely took tremendous amounts of personal experimentation when my body was much smaller. I probably had some assistance, but that knowledge had to be developed by me.

There are far more situations, however, in which we must rely on secondhand data. If one wants to do a good job at living, there’s a lot to know–one simply could not acquire so much information on their own. This is where the help of others comes in: the data they know, the lessons they’ve learned and can teach us.

It seems likely that these same principles describe when one should write code themselves or use existing code. You pretty much couldn’t write all the code yourself down to the hardware level and come up with some of the most useful software we have today. For sure, there are some things that only we are uniquely qualified to write–usually the specific logic of the product that we’re working on. But there are many more things that we must rely on existing code for, just like we must rely on existing secondhand knowledge to survive as individuals.

It’s also possible we could use this principle somewhat for deciding how to divide up work between developers. Would it be faster for somebody to create a piece of code out of their firsthand knowledge, or would it be faster for a group of people to look at the existing system (secondhand knowledge) and start to contribute their own parts (which will, in time, essentially become their firsthand knowledge)? The answer depends on the situation, obviously, and though the basic idea here may not be too novel (some programmers already know the system better than others and so they’re faster) the way we came to the idea is what matters. We first theorize that software is knowledge, and then suddenly we can see a clear logical line down to some existing principle that is already known to be generally true. Pretty handy, and indicates we could likely derive other, more useful information from this principle.

Of course, this is not, by itself, a science or a scientific system. It’s just an idea, one that seems to work well for deriving principles about development. I would say it is one of the broadest philosophical theories that I’ve been able to develop about software, in fact. It seems to cover all aspects and explain all behaviors. I could actually sit here and theorize about this idea all day, but I’m not here to ramble, just to give a brief summary and then see what you have to say about it.


4 Responses to Software as Knowledge

  1. Mars says:

    Hi, Max
    Good posted!

    What I want to share is that software developer/desinger should take more time to learn philosophy knowlege,
    It’s very useful for us to design and make the knowlege to good software with quality codes.
    Software as knowledge, it’s need to come from the super-human with super-mind.


  2. Mike W. says:

    Interesting point. I differ slightly: I think all software is composed of DECISIONS and nothing else. 🙂 (Decisions are a more specific type of knowledge.)

    Of course you could propose that ALL knowledge directly proceeds from decisions, at which point it would become moot. (And indeed that may be the case, since we’re talking philosophically.) But I think referring to software as “decisions” is better as it places more emphasis on the changeability of those decisions. By contrast, most people view “knowledge” as something which comes from outside of themselves and which cannot be altered. (The tallest mountain in the world is ____ and it is ____ feet high.) Decisions, on the other hand, can be harder or easier to change. So it gives a clearer connotation.

    Building on the DECISIONS made by the chip designer, the firmware designer, the OS designer, the compiler author, the language designer…you place your own decisions into the computer and the result is software. (If you don’t *understand* the decisions made by e.g. the language designer, the result is syntax errors.)

    A “hack” can then be defined as “making new decisions instead of inspecting and fixing old decisions.” Which is, I think, the point of “Make It Never Come Back.” (

    Much as you, I could sit here and extrapolate from this one principle all day, but I just wished to communicate what for me has been a fundamental working principle for understanding all things computer-y. 🙂

    • Max Kanat-Alexander says:

      Sure. I know that you and I have talked about that in person before, too.

      I think it’s simpler to view it as knowledge, as most people won’t really understand what to do with “decisions,” but people have lots of experience working with knowledge. If you point out that a program is like a big book that a hundred people are writing in at once (the only good analogy I’ve found to explain organized programming to non-programmers) then people understand the problem. It doesn’t just work to solve the problem—it works for communicating the solution to others.

      The thing that you have to think about is that most programming involves working with existing systems, not making new ones. A “decision” is something that you do (from most people’s perspective), but software for most programmers is something that they have. so it’s simpler to look at it as “knowledge,” which is the thing that you have.

      There’s a lot more that I could say about this, but probably easier to talk about it next time I see you.


Leave a Reply

Your email address will not be published. Required fields are marked *