Living Software Design

This is an attempt to organize some thoughts on an approach to designing software. It is an attempt to introduce a flowing generative quality to the process of thinking about a software ecology.

It is not bound to any specific implementation tools (design, management or coding). It's elements and artifacts likely can be mapped to other tools and methodologies.

The building blocks are:

1. Beings - the entities that partake in the software mediated experience.
2. Relationships - two or mote beings can be associated via relationships.
3. Indicators - relationships accumulate indicators that describe the state and potency of the relationship.
4. Transformations - Transformations are potential actions that the software ecology provides to the beings in a relationship. An enacted (by a being in a relationship) transformation can change indicators and thus change the state of the relationship.
5. Sequences - sequences weave together indicators and transformations into generative (evolutionary) paths within the software ecology.

1: Beings

Any entitty in the system is treated as a being with agency to act. There are two types oe being:

1. Human Beings (users) who partake in the software ecology are living beings who bring to the ecology their own agency. They respond to capacities in unpredictable ways but their responses converge into the transformations made possible within the software ecology.
2. Mechanical Beings manifest within the software ecology and their agency is predetermined as part of the implemented software ecology. They respond predictably and reliably to their capacities within their relationships. RElating to them as beings allows to imbue their "functionality" with motivations, with striving for outcomes, perhaps even with doing good.

Beings share in aspirations. Aspirations are inherent in human beings. They can be designed into mechanical beings. But, maybe most importantly, when the two interact new aspirations can arise.

Example: Entities in a Blog

1. Author: a human being who controls the blog and published content on it.
2. Blog: the blog itself is a mechanical being that is at the root of the software ecology.
3. Post: a post is a mechanical being that is created by an author and represens a unit of content.
4. Reader: a human being who can visit the blog and read posts and comment on them.
5. Comment: a mechanical being that represents another unit of content that is created by a reader and is related to a post.

2: Relationships

Beings come to life in relationships. Relatonships create the need and ability to act.

Example: Relationships in a Blog

The beings can form the following relationships:

1. Author-Blog
2. Blog-Post
3. Author-Post
4. Reader-Blog
5. Reader-Post
6. Reader-Comment
7. Post-Comment
8. Blog-Comment

3: Indicators

Indicators say something about the state of a relationship. Indicators are an outcome of past transformations. Indicators act as keys to potential transformations: when a relationship is in a given (by its indicators) state different things become possible for the beings in the relationship.

Example: Indicators in a Blog

At this point there is a potentially exponential growth in complexity so the following are merely singular examples in the different relationships that are possible within a blog.

1. Within the Author-Blog relationship an indicator "creator" indicates that the author is also the creator of the blog. This was caused by the author creating the blog.
2. Within the Blog-Post relationship an indicator "published" indicates that the post has been made public. This was caused by the author (within the Author-Blog relationship) publishing the post.
3. Within the Author-Post relationship an indicator "creator" indicate that the author is also the create of the post. This was caused by the author (within the Author-Blog relatioship) creating the post.
4. Within the Reader-Post relationship an indicator "read" indicates that the reader has seen the post. This was caused by the reader (within the Reader-Blog) relationship when the reader first viewed the post.
5. Within the Reader-Comment relationship an indicator "creator" indicaes that the reader is the creator of the comment. This was caused by the reader (within the Reader-Blog relationship) creating the comment.
6. Within the Post-Comment relationship an indicator "approved" indicates that the comment has passed through moderation. This was caused by an author (within the Author-Blog relationship) read and approved the comment.
7. Within the Blog-Comment relationship an indicator "clean" indicates that the comment does not have malicious content embedded in it. This was caused by the blog (within the blog-comment relationship) when it scanned the comment and found it has not malicious code embedded in it.