Wednesday, March 9, 2011

EVA: The Design Principle of Essence Versus Artifact

2017 Update: It took me 7 years to realize I was one tick away from a great acronym for this principle. Instead of "Essence and Artifact" (EAA - awkward!), I realized the inherent tension between essence and artifact is better expressed as Essence VERSUS Artifact, or EVA. Now, back to what I wrote about it in 2011. -SBD

I’m a designer and builder, and I highly value well-designed things. I both enjoy well-designed things made by other people, and I enjoy making well-designed things myself. I spend a lot of time thinking about what it means to be well-designed. There are many ways to measure the quality of design including aesthetics, form, function, and cost, but there is one design principle I find to be most important. I call it: Essence and Artifact.

What is “Essence and Artifact”?

There are two kinds of constraints on design. The universe we live in forces physical and logical constraints on what is possible. These essential constraints are inviolate. We can't change the charge of an electron anymore than we can change the value of π. These constrains define an upper bound on what is possible when designing a solution to a problem. This upper bound is what I call the “essential solution” to a problem. It is often unachievable in practice, but it is the goal any designer strives for and the benchmark by which all solutions are measured.

In addition to the essential constraints of the universe, we are also constrained by historical artifacts. Manufacturing may settle on standards, and though that standard can be easily rewritten, retooling the infrastructure based on that standard may become an economic impossibility. Similarly, virtual architectures, such as the Intel x86 instruction set, are so economically entrenched by all the software that depends on them, that they can't be practically changed. In addition to constraining our options, artifacts constrain our thinking.

The Essence and Artifact Design Principle

Understand which constraints are essential and which are artificial.  Once the artifacts have been identified, discard as many of them as possible the design to approach the essential solutions for the problem.

Keep in mind that every actual thing in existence is an Artifact and is in some way non-essential. However, if our designs approach the upper bound of the essential solution then by definition there is little room to improve upon them. In other words, essential solutions are also timeless, and I think “timeless” is an excellent measure of good design.

Future Posts

In future posts I hope to dive deeper into some of the implications of E&A. Below are a few of the key attributes of each:

Essence is:
·      Timeless
·      Simple
·      Powerful (Maximally applicable)
·      Modular
·      Focused
·      Theoretical

Artifacts are:
·      Historical
·      Complex
·      Constrained
·      Difficult
·      Narrowly Focused or Unfocused
·      Actual


  1. Awesome!!

    "Keep in mind that every actual thing in existence is an Artifact and is in some way non-essential." - A very Buddhist idea. In a recent book, the Dalai Lama talks about how we view the world through the lens of our own concepts - abstractions that we use to make sense of the world.

    What's interesting to me about the world of software is that - just like the real world - it's a constructed of abstractions. With software, more than in the real world, I think, these abstractions can be leaky or inappropriate for certain situations - more artifact than essence. The hacker and Buddhist both know that everything is an abstraction, and strives to manipulate or discover the essence.

    But discovering this essence takes time and energy. That is the whole reason for the abstractions in the first place. We need the abstractions in order to make sense of the world, because we don't have unlimited time, attention, and knowledge.

    So, maybe the question we should be asking is: how do we create abstractions that degrade properly to expose the essence, rather than abstractions that obfuscate the essence with artifacts?

    Another question is: along the lines of the model-view dichotomy, is it (or should it be) possible to *change* your abstraction as might fit your present circumstances?

    I think human beings do this all the time in the real world; for example one day we might see Charlie Sheen as an amicable funny man, the next we might see him as a dangerous lunatic. Both pictures of reality (Stephen Hawking would call them "models", not to be confused with data models) are beneficial for certain purposes. Which best reflects the essence? In all seriousness, I'm not sure it's possible to answer that question.

    Right now, in code, we're restricted to the single set of abstractions that was laid down by the developer before us. Would it someday be possible to change our abstraction as may suit our conditions? That would be a neat trick.

  2. Excellent thoughts Jason. I also noticed how close my idea of "Essential" solutions is to the Platonic Ideals ( ). In some sense, these are perfect ideas which are not achievable in reality, but are worth striving for.

    In some sense I am advocating striving for some indescribable perfection. I hope to elaborate more that I actually have a semi-objective notion of what these Essential Solutions look like, but overall I do realize that striving for perfection can lead to paralysis. You have to ship sometime. It's been my experience though, that with careful thought, you can put in 10% more effort and get a system which is 10x better - much closer to an essential solution.

  3. This comment has been removed by the author.

  4. We are providing affordable Rubber Roofing Services, click here to book an appointment.


Note: Only a member of this blog may post a comment.