What's your code?

The German sociologist I’ve been studying didn’t like computers. He preferred reading words on paper and near the end of his life he typed on an electric typewriter. But his theory of society works well in the computer age, and I’ve been thinking about how his work could be used to design applications. I see three steps the developer could start with: communications, code, and programs (referring to the codes and programs in a system).

• Communications: Think of an application as an operationally closed system made of communications that regenerate the system (more communications). Here on Lifelog my post increments the streak counter which encourages me to write the next day. That’s the basic communication loop, but there are other forms of communication that keep the system running like comments and badges.
• Code: Code means a binary distinction that defines the focus of the communications in the system. There should be one and only one code. On Lifelog that might be “counts / doesn’t count” as part of the streak. This simplifies the complexity of the system. The user knows what to expect of the app.
• Programs: The programs define how the system determines the validity of the code. These programs are pinned to the code, but can have a lot more flexibility. Here on Lifelog the programs are a bit rigid: one hundred words or more, posts on consecutive days. So there is not a lot of discussion around the code “counts / doesn’t count”.

An Example

A developer making a cooking application could start by looking at the communications as a system. Recipes help the user develop a weekly meal plan. The plan helps to set up the meal schedule. This triggers cooking sessions based around the recipes. And then this leads to a rating of the recipe. (Notice: If the rating doesn’t feed back into the meal plan, the cycle is broken.)

Looking for the code, the developer might decide it should be “satisfying / not satisfying”. All of the communication in the system is focused on this question of, “What makes a satisfying meal?” This is the code that defines the system. But what makes a satisfying meal is going to be different for different people, so this will create a lot of discussion on a focused topic.

The programs are pinned to the code, but can have a lot of variety. What do people find satisfying? The flavors, the cost, the prep time, the variety? The developer would consider building functions around those distinctions. Maybe a tool helps the user define a flavor profile they’re looking for, or lets them set a budget. As long as these “programs” relate back to the code, they should contribute to the active regenerative nature of the system.