This post serves as the underpinning for a number of other posts that are or will be on my blog.

Intro

This article will introduce a model for how to conceptualize the process of understanding a system.  The system models a subject area as a cloud of connected points, where each point is a fact, and each connection represents a relationship between those facts.  This system of modeling can be used as a basis for developing concrete expressions of cognition.

Consider the Sandwich

As a means of illustrating this modeling system, let’s look at applying it to the making of sandwiches.  We’ll start with a single sandwich.

The box above represents the fact that a pastrami sandwich is an identifiable entity.  This is a fact that a person can learn, nothing more, nothing less.  Knowing this fact implies no other knowledge though, so let’s add some more facts.

We’ve added some more facts to the map here.  The sandwich is made of other things.  Note that the components are separate things from the fact that the sandwich is made of them.  You can know that both brown mustard and pastrami sandwiches exist, but not that the sandwiches are made with mustard.

Also, note that the relationship is directional.  It’s the same fact conceptually, but depending on which direction it is approached from, it looks like a different fact.  This implies another fact we can add.

Something can be a composite object, meaning it is composed of other things.  All our ingredients are also composite objects, though (mostly for readability) the implied Made of/Ingredient in nodes for all those ingredients are not included.  However, this illustrates an important point.  You can know that a pastrami sandwich is a composite object, and that all the ingredients are also composite objects, and even that the sandwich is made of all the ingredients, but still not know that the sandwich being a composite object infers that it is made of things.  This inference is key to extrapolating additional meaning from the links between Composite Object and each ingredient.

The Secret (of the) Sauce

Let’s zoom in on the brown mustard.  While the actual implementation of the sandwich is explicitly and exclusively brown mustard, that doesn’t mean that that is the interpretation fixed in the minds of the people learning this fact map.  One person may recall it as “yellow sauce”, another just “mustard”, and the guy who hasn’t had to make a pastrami sandwich in 18 months may just remember “there’s a sauce or something here.”  While these are all valid recollections of the core fact, they, and their differences, are important for understanding the complexity involved in having multiple people work on this single sandwich domain.

The “yellow sauce” person might think that lemon pepper dressing is a valid option, the “mustard” person would think that yellow mustard qualifies, and the “maybe sauce” guy could think that he might have misremembered and it’s supposed to be cucumbers, not a sauce at all.  In isolation, all these different interpretations could be accounted and adjusted for, but if these people are coordinating on making sandwiches, it could lead to thoroughly unpleasant food, or an incorrect order being placed with their supplier.  Visually, we can represent this in our model as a cloud of interpretations connected to the actual fact, creating a cloud of understanding around the given fact.

Another point to call out here is that these understanding points shift over time.  There’s an implied statement above in that the “maybe sauce” guy used to know more detail, but as his distance from the topic grew  and focus shifted in his role, his memory got fuzzy and faded.  Assume he spent the last 18 months prepping veggies, so his focus has shifted from sandwiches, and that’s why he’s putting cucumbers on the sandwich now when he’s pressed into service on the sandwich line.

Now we can start to see this cognition model incorporates a number of things about team and time dynamics, not just purely the pure facts.  From this, we can start to derive a quantifiable measure of complexity of a system in context of the organization that works on it.  This measure can be used to evaluate the cost of different organizational, process, and architectural changes on the complexity of making changes to the system.

Moving Toward Measurement

Let’s step back from the sandwiches now and generalize.  Consider any system modeled as a cloud of facts, with each fact in turn modeled as a volume enclosed by the points of understanding of the team members that directly interact with that fact, with each team member being plotted as a new dimension.  That then makes a starting point for a formula for the complexity of any given fact:

c*d^(1+(mp))

c = base complexity of the fact

d = average distance of the points of understanding for a given fact

m = a constant, to be determined by experiment, which at least in part represents the likelihood that a team member will need to talk to another team member to make progress on a given change for that fact

p = the number of people who work directly with the given fact

The complexity of the system, or any slice of it, is then the sum of the volumes of all the fact bubbles for all facts within the system or slice.  One important take away is that the impact of team size on change complexity is exponential.  This is a trap that many organizations fall into, because when a team is small, c overwhelms the other parts of the formula.  However, teams hit an inflection point with both d and p, where the solutions to complexity that have worked in the past no longer do, and in some cases are actively counterproductive.  I will expand on the implications of this and more in future posts.