Software for Trusting

There is a lot of cruft and unnecessary abstraction in the code and programs that we use every day.

Most of the data that is shown to a user is irrelevant; a fraction of the information stored in RAM is actually “readable as usable” for the person in front of the screen. That’s probably OK; to take an example from real life, we don’t need to understand how DNA works in order to grow or live our daily lives. But when it comes to computers, we are responsible for representing and managing data efficiently.

Is the amount of information downloaded from the network in the right order-of-magnitude for the level of risk of correctly understanding that we deem acceptable? For example, when one uses Expedia, and downloads megabytes and megabytes of JavaScript and images, it’s hard to say the browser is being an efficient representative of what the user wants. Browsers in technical lingo are called “User Agents” – are they actually, representatives of the agency of the User? Their actual needs might go along the lines of “show me which flights go from Paris to London”, and “what options do I have, and what are the costs and total travel times”. Excluding cases like booking a hotel, where pictures and videos of the place (and the millions of bytes required for representing such multimedia files require) might be necessary to make an informed decision.

I dare say that we’ve lost track of how to build malleable software, software that we can use just for what we need and want, in a particular moment. The software that we currently have is custom made for corporations to maximize profits. They serve the long tail of usecases, and in order for the corporation to be efficient, it has to harvest the user for data so we can improve the profits of corporations. This is not intended to be a moral judgment of any kind – it just the way I think it works right now, however “good” or “bad”.

A program’s functionality and effects on the environment (particularly, the network and other computers to which the program communicates) should be explained in the user experience. The user needs to understand how the system will act on its behalf. This is an educative function. It’s not easy to create a shared understanding of how the system works; we’re used to systems that just “work” for us with a very simple interface that doesn’t reveal many details.

Not even programmers generally get this kind of understanding. Documentation and reading already existing code make up for most of the time spent for developers of software systems. It’s estimated that making a change requires up to 4 times more time of the developer understanding the system and how the proposed change will affect the code.

So what will the best path forward looks like? I think one of the most interesting things we could create is software that is self-explanatory – where the source code is in the shape of graphical explanations of how the data flows between the different computers that make up the system. This won’t be easy – it’s pretty hard to create self-explanatory infographics – let alone, have them also be executable!

What are the primitives that these graphics should have? Whatever primitive we introduce here needs to be generic enough as to be the “initial understanding” of the system. Should we go as deep as try to explain how electricity works? Maybe not. But some elements of that representation should definitely contain some concept of what a user is, what a CPU is, and other basic divisions of concious/agent executors. In a chat program, one would have to introduce concepts such as what a conversation and messages are, what shape/contents such messages have, and of course, what other users are, and which other computers does the system contact.

With such a system, one can now allow the user to change this program and this representation, to achieve new functionality through modifying this chart of what are the information flows. There’s an interesting distinction here between what the blueprint of one user has regarding what another user has. This is what we call the differentiation of a protocol with the program interpreting and implementing that protocol.

And that opens up the conversation towards how to upgrade such systems, how to reach consensus about which protocol to use, changes and modifications to it. But that’s probably a topic for another essay.

Cheers,
Claude