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.


7 Responses to Software as Knowledge

  1. Pingback: Software as Knowledge – coding | factory

Leave a Reply