In the field of designing control systems, there’s a heuristic that states “keep your feedback loops tight.” My knowledge of control systems engineering is a bit patchy, but I suspect this has to do with minimizing the delay between an event in the real world and the system’s perception of it. The tighter the loop, the easier it is for the system to respond to it’s environment. (Upon googling, I’ve found that this heuristic might be for the benefit of the design engineers rather than the system itself.)

It’s not even necessary to bring in perceptual control theory to apply this to humans. The quicker the feedback, the more accurately you can adjust your actions to produce the desired outcome. I’ll dig up the links later, but I believe the brain is optimized to perform over short causal distances, actions followed immediately by results. When that information is delayed, it creates the opportunity for uncertainty, so when it finally does come, the effects are severely reduced. Learning is hampered. That’s why unambiguous feedback is one of the requirements for entering a flow state. (Anecdotally, I can place much of the difficulty of my job squarely on the fact that we’re forced to operate with months-long feedback loops).

Lately it’s occurred to me that I can apply this heuristic to my thoughts themselves. As far as adjectives go, ‘tangled’ is generally a fairly good one for describing my thought processes. ‘Hazy’ is another one. Except for brief moments of clarity, most of them bear little relation to reality, instead being steeped in various biases and incomplete-understandings. 90% of the time I try to ignore what goes on in my brain.

But that sort of half-assery doesn’t fly when I’m writing. For some reason, seeing the words in front of me makes me that much more cognizant of them. When the words get put to the page, it’s immediately apparent whether they’re sensible or need a healthy dose of backspace. Writing, perhaps because I use different parts of my brain when I’m perceiving outside stimulus, foists clear (or at least, clear-er) thinking onto me.

My hope is that by writing often, and getting near-instant feedback to the sort of thoughts I’m having, that I can ‘train’ myself to think more clearly, to not fall prey to biases and mistakes of logic that (ideally) I would notice immediately.

Failing that, at the very least writing more will at least produce that many more hours of clear-thoughts in a day.

Systems Engineering is one of the ‘hot’ disciplines right now. According to CNN, it’s the best (or highest paying, or fastest growing, or something) job in America. That’s not why I’m pursuing it, but it at least makes for a nice talking point should the moment require one. Unfortunately, it’s sister sciences, which I happen to be more interested in, haven’t fared as well. “Systems Science”, emphasis on the quotes, has been with us for nearly a hundred years now, but its contributions have been few, it’s tenets are vague, and it’s populated by a few too many nutjobs and crackpots for my comfort.

So, to both improve my understanding of the field and to try to break down what exactly you’re studying when you’re studying “systems”, I’m proceeding with unpacking and exploring some of the basic concepts of the study of systems. It’s a field full of cool-sounding ideas and impressive buzzwords, but how much meat is on those bones? Lets find out.

I’ll jump right in with a big one: complexity. Whenever you see the word ’system’, you can bet that the word ‘complex’ is either tacked on in front or lurking somewhere in the paragraphs below. Simple systems don’t merit study – they tend to fall into the category of already-figured-out. So-called ‘complex systems’ are a large part of why there’s able to be a ’systems’ discipline at all.

But what is complexity? Like many buzzwords, it’s gotten defined over and over again, in a variety of ways. Even in the comparatively more rigorous field of computer science, it seems that everyone and their mother has concocted some definition of complexity. Here’s a short list:

Computational Complexity – From ye old wikipedia, computational complexity “is a branch of the theory of computation in computer science that focuses on classifying computational problems according to their inherent difficulty.” It’s related to finding efficient algorithms for testing and solving problems of various kinds. P=NP is the classic, unsolved problem in computational complexity.

Kolmogorov Complexity – Kolmogorov Complexity is a description of how complex a piece of data or information is, making it closely related to computational complexity. Essentially, the Kolmogorov complexity of a particular sequence is the length of a computer program necessary to output that sequence. The longer the program, the more complex the sequence. Interestingly, under this definition (unlike many other definitions of complexity) a random sequence is the most complex you can get, since it’s impossible to compress. Kolmogorov Complexity is a description of the regularity of a piece of information (from perfectly regular to perfectly irregular) rather than what we would typically intuit to be its complexity. It also has the irritating property of being uncomputable, which hamstrings it’s usefulness somewhat.

Statistical Complexity – (or Effective Complexity). Bear with me as I google. Unlike Kolmogorov Complexity, Statistical complexity seems to be related to the structure present in a particular process – perfectly periodic and perfectly random processes possess no structure, and so are simple as opposed to complex. Statistical complexity is concerned with the degree of pattern or regularity in a process (though I confess what you might use to measure that escapes me). Like Kolmogorov Complexity though, the means of measurement of Statistical Complexity is the length of the computer program that outputs the regularities of a sequence.

The above are all closely related to, or subfields of, Information Theory – they’re about data compression and algorithmic performance. But none of these are what you tend to think of, or what systems engineers refer to, when they talk about something being complex. Let’s make that short list of definitions a little bit longer:

Biological Complexity – Now we’re headed towards familiar territory. Because biology isn’t developed to the point where it can completely describe the processes that produce a behavior, measures of biological complexity tend to based on form, function, or the genetic sequence that codes for an organism. These measures can be tricky, as it’s seldom obvious where to draw the line between different structures or behaviors. And though both are determined (at least initially) by genetic code, the fact that there’s a gap in our understanding between what the gene says and what the organism is and does means that currently it’s not the most useful definition, although in time it may end up being the most accurate.

Physical Complexity – Posited as a measure in the paper where I stole most of my definitions from, physical complexity is a measure of how much information about the environment is contained in a particular sequence. For example, the more information about the environment a gene stores, the more adaptive behaviors it is capable of specifying, and the more complex it becomes. “If A then B” is much less complex than “If A and C and E given G H and I previously, then B F and Q”, although I wonder if the physical complexity of gene sequences might level off once they’re capable of producing organs (such as minds) that can store information about the environment in a different fashion. More precisely defined, physical complexity is a measure of the shared Kolmogorov Complexity of a sequence and its environment.

These definitions, though relating to the physical world, are still rooted in information theory – genes coding for an organism is no different than a computer program outputting a string of data. Moving away from these definitions brings us closer to what we traditionally think of as complexity. Unfortunately, this serves only to illustrate the uselessness of those intuitions:

From the wikipedia article on “complex systems”:

A complex system is a system composed of interconnected parts that as a whole exhibit one or more properties (behavior among the possible properties) not obvious from the properties of the individual parts.

From the wikipedia article on “complex adaptive systems”:

A CAS behaves/evolves according to three key principles: order is emergent as opposed to predetermined (c.f. Neural Networks), the system’s history is irreversible, and the system’s future is often unpredictable.

From a MITRE newsletter:

“Complexity is a fuzzy concept,” says Lashon Booker, principal engineer for the Center for Washington Command, Control, and Communications (WC3). “There are prototypical examples of complex systems, such as economies and social systems; however, trying to draw boundaries and determining that everything inside is complex and everything out isn’t, I think, misses the point. Complex systems typically have some characteristic properties, but the extent to which a particular system exhibits any given property can vary.”

This is what often gets referred to when discussing ‘complexity’, and it’s the least precise definition yet. Read about ‘Complex Systems’, ‘Complexity Theory’, or other miscellanea with the word ‘Complex’ in it and you’ll see a vague definition like the one above, and a list of the properties that supposedly characterize a complex system. These include:

-emergence
-non-linearity
-self-reference
-fuzzy boundaries
-an open (as opposed to closed) system

These topics all have something in common: they’re all poorly understood, almost as if someone drew a line around a group of topics we haven’t figured out and called it a field of study. Some pattern seemingly ‘emerges’ out of nowhere? Complexity! Feedback loops causing unpredictable behavior? Complexity! Non-linear or ‘chaotic’ behavior that can’t be foreseen? Complexity! Don’t know where something starts or stops? Complexity! Self-reference or deep, recursive hierarchies doing something weird? Complexity! You can’t talk about any of them without using the phrase “don’t know”. It’s a field defined by our ignorance.

Take traffic, for example. Traffic/road systems have many of the properties of supposed complex systems – many small agents, fuzzy boundaries, an open system, etc. But they’re seldom talked about as an example of complex systems because we’re not ignorant of them – traffic pattern analysis and traffic engineering are well-defined disciplines. It’s only when we fail at understanding something that we apply the complexity label to it.

And I strongly suspect that these ‘mysterious’ behaviors of complex systems are really problems of computation or information theory in disguise. For example, one of the few useful concepts to come from the field of cybernetics is Ashby’s Law of Requisite Variety, which states: “The larger the variety of actions available to a control system, the larger the variety of perturbations it is able to compensate.” This seems little more than a restatement of the definition of Physical Complexity. And the only coherent definition of ‘emergence’ that I’ve come across has been an information-theoretical one.

So when you’re talking about complexity, you’re talking about one of two things:

1) A computer program outputting a sequence of data

2) Something you don’t understand

Systems engineering is about engineering a process, about creating something that does something. In principle, any process can be viewed as a computation (though I’ll bet many systems scientists would love to invoke the magic of ‘holism’ to explain why that isn’t the case), bringing us squarely into the realm of Information Theory. In short, complexity, fuzzy topic it may be, is over-defined. Problems of complexity are problems of computation or information theory in disguise, and any attempt so study or solve them will have to either look to those disciplines, or forgo a mathematical answer and use a heuristic, intuitionist approach. But pontificating about the magic and mysteriousness of complexity, as systems people seem to enjoy doing, is unnecessary. You can stop writing papers about “What is Complexity?” – we don’t need any more.

Hello blog. It’s been awhile. You’re looking good.

I’ve missed you.

Anyway.

A heuristic that I’ve seen pop up, in several different arenas, is the principle of doing more with less. To be successful, really successful, it’s necessary to strip things down to the absolute minimum. Find the essence of what you’re trying to do, and, to the extent thats possible, focus on it to the exclusion of everything else*. If you can make that raw essence exceptional, everything else will be easy.

Fine, I can roll with that. My problem is that it’s a deceptively difficult trick to pull off in practice.

Sure, it sounds easy to just trim away everything superfluous from your raw passions… until you’ve tried to do it, and find yourself left with… *counts*…a list of seven or eight things that you still think you need to focus on. Several months ago I wrote that I found myself being driven by three masters. They seem to have multiplied since then. It’s not something I can come close to satisfying, much less sustaining.

Of course, this just means that I haven’t yet found the essence of what I’m trying to do (which is it’s own disappointment, given that it’s been bouncing around in my head for months at this point). What I have is seven or eight lenses onto something more basic beneath, something I haven’t yet completely grasped. That needs to be my next step – until I do, my actions will be muddled, pulling me in seven or eight different directions instead of where I want to be going.

*Bonus points: this bears a striking resemblance to my favorite definition of mathematics, “the minimum environment to preserve ideas”