the third attempt

This is the 3rd attempt. My previous attempts were placed in the wrong books: The Fifth Discipline & Complexity Science.”

It was only after enrolling for a “Intro to Systems Engineering” course, “stealing” the syllabus, reading the textbook, and reflecting on it’s content that I can say I somewhat understand it now.

Reading the book was exactly what I needed, because I spent way too many times reflecting on the same concepts, when I could have just read the book. But hey, I can feel proud of myself in the fact that I was able to get to these topics via “reflective thinking.

reifying values

“An effort to represent a complex system by an index of performance seems analogous to attempting to represent reality with a measuring stick”

“Why do you sociologists exhibit such a pathological resistance to closure?”

One of the most important activities conducted when performing “systems analysis” is creating metrics for “success” or defining what your “good” system looks like. I’ve always recognized that tasks like these are “ultimately” unresovable, but “pragmatically” resolvable.

I mean Plato has been asking the same questions of “Justice” and other alike virtues/values since BC. But all hope isn’t lost if some Roman philosophers couldn’t figure it out. Because we have an Austrian one named Wittegenstein. Values can be contextual and quantifiably defined in context of their use.

What “fast” means is contextual, but for a given system you can define stuff about it. “Fast” can then refer to a time threshold depending on the system, which doesn’t seem to crazy of an idea. The resolution of these “values” is exactly what the sociologists referred to in the quote above spend all their time on.

I think the takeaway is understanding what you are doing by creating an “index of performance” and applying it. That it is always going to be a part of the whole. But it is wholly important to do so if you want analysis to proceed1.

models, implementation, & behaviour

“What does the mathematics care whether you write it in ink on paper or write it with electrons in a computer?”

The quote is an illustrating quote. It validated a good deal about how I was thinking about the difference between the syntax of modelling and the syntax of behaviour.

The difference being that we describe simulations using mathematical or computer syntax. These simulations “run” whether that be calculating a system of equations or updating a grid on a map. Then we describe the simulation’s “behaviour” with plain English words or visualize it using the data the simulation generated.

The point being, you may use a language to implement the system i.e. a coding language or mathematical symbols, and then another language to describe it’s behaviour in terms of metrics or invariants.

An all to familiar example of this is debugging with “print statements” instead of using asserts.


  1. Never make it the target. Think of all the metrics a company will use to incentivize “good software development” and how often it is gamed.