Aesthetics Of A System As Prime Indicator For Technical Health

10-02-2026

The Search for "Whatness"

In my previous work on abstraction, I viewed it as a tool to manage complexity by intentionally ignoring details. (I encourage the reader to familiarize with this article before hand or at least opening it up side by side, to follow along with some established ideas and examples.)

However, I felt I was missing the "essence" of my approach. I have since found that missing piece in the Aesthetic Attitude: a perspective that looks at a system not for what it can do for us, but for what it is.

While a functional approach asks, "How do I make the vacuum suck up dirt?", the aesthetic attitude asks, "What is the logic of suction?". This is a state of Aesthetic Arrest—the moment you stop looking at a system’s utility and start looking at its internal form. I believe that to build healthy systems, we must move from mere Functionalism (focusing on features) to Integrity (focusing on the internal rightness of the model). From what does it do to, what is it?

Quiddity and Haecceity

To understand a system’s "Whatness," we look at two specific concepts:

In scholastic philosophy, quiddity and haecceity are used to define the essence of a thing through its shared and unique characteristics. Quiddity (from the Latin quidditas) refers to the "whatness" of an object, describing the universal properties it shares with others of its genus, such as the general collection of characteristics that make a tree a tree. What makes a tree a tree? Why is a flower not a tree for example?

In contrast, haecceity represents "thisness"—the irreducible determination that makes an entity this particular thing rather than just a generic instance of a category. So what makes a particular tree, this tree instead of any other tree.

In software, the codebase is a Conceptual Model rendered into language. Technical health is reached when the code possesses Haecceity—when it is a perfect mirror of the internal logic of the mental model it represents, yet remains flexible and able to change by respecting the Quiddity of it's components.

Ok enough philosophy — let's talk examples!

Internal Rightness: The Shot List

In a Virtual Production workflow, a functional approach would represent a "shot list" as a literal data object containing a list of sequences. You would reach that conclusion quickly. You think of Data and Algorithms. You think of it like the easiest way to bridge individual pieces into a structure you can iterate and render out.
Reference to full example.

The Failure of Function: This matches the Quiddity (the general idea) of a list, but fails the to address the Quiddity of a Shot and the Haecceity (the specific needs) of the workflow. A tabular list forces Hard Mental Operations because the user has to remember where shots ended to ensure continuity; the physical relationship between the camera and the stage is hidden.

The Aesthetic Rightness: By looking for the "Whatness" of a shot—the framing of a scene over duration—we can represent it as a physical actor object in the game engine.

• Predictability: Because the shots are now physical objects, overlaps and continuity become visually obvious.

• Technical Health: Because the shots follow the internal logic of the engine, we get features for "free," such as using existing recording tools to stream camera data directly into the system.

Digital Sculpting: Extending from Established Truth

When you identify what a system "wants to be," building it becomes Digital Sculpting—chipping away everything that isn't the "Truth" of that system. Or working a new piece into the existing form by first adding to it and then smoothening it in. It really depends if you view my "sculpting" metaphor as a chipping activity or a molding activity. But the idea is the same. In this case I want you to focus on the Quiddity of Sculpting and not the Haeccity of Marble or Clay sculpting.

Consider the Movie Render Queue. Reference to full example
A functional approach might involve writing complex, custom code for every edge case. Having to test all of them, ensuring that there are no new edge cases that were not covered. Hoping that through these new implementations you are not upsetting the remaining system. Adding custom functionality to an existing system can be very scary. Especially when that system is Unreal!

Instead, the aesthetic approach looks for the established rightness. In the sense of the sculptor the already perfectly molded main body. By attaching yourself to the existing system -- for example creating a fake Render Queue job — we force all edge cases to fit the main logic, which is already correct. The convergence of two unrelated modules to one single source of control also reduces Viscosity(the difficulty of making changes) because new features fit naturally into the existing flow.

The Golden Rule of Technical Health: Single Source of Truth

An "Ugly" system is Mundane—its rules are scattered across different modules, multiple lines or an entire class. This invites confusion and leads to technical debt because it requires too much mental effort to track the system's true role. The system is not revealing it's true intent through it's own structure.

My Golden Rule for a healthy system is: Every rule or idea expressed should have exactly one place. One source of truth and control — reiterating the previous point. For example, automating VCam possession—which originally required twelve arbitrary steps hidden in the UI—replaces "hand-holding" data with a Single Pulse. Reference to full example

This directly links the user's intent and the system's behavior. The user engages with a single point of invariable truth: the call to "Possess VCam", while the multiple steps underneath, involved to implement that action, can change indefinitely. This is where abstraction becomes the tool to reach an aesthetic ideal.

Conclusion: The Path of Least Resistance

I am not saying you should discard a pragmatic stance altogether in favor of chasing some ideal model in your code, without it ever doing anything useful. But little by little I invite you to consider the internal rightness of what you build. I have found for my self, that doing this often helps me to have a very easy time to extend or add new features, sometimes even getting some for free, before my creative director was even thinking about them.

Technical health is not found in trying to predict the future. It is found by judging a system from a non-utilitarian perspective to see if it is correct and can change easily because of that inner "rightness". A clear separation based on Quiddity and Haecceity. When we respect the Aesthetic Integrity of a system's "Whatness," the architecture becomes Predictable and Intuitive, realizing a potential that was already there. And when we recognize components "Thisness" than we encourage clear boundaries, single sources of truth and insure that we can navigate and change it more easily.