The Ballet Law

In ballet, every class from age two to professional to retired starts with the exact same step. You never move on from the single fundamental. You grow, you develop artistry, you cloak the fundamentals in it, and the two are intertwined inextricably.

I trained for fifteen years before I ever wrote a product spec. I have been thinking about that structure ever since, because software teams get it exactly backwards.

Fundamentals are not setup

The mistake is treating the fundamental as a phase. You stand up CI. You build the design system. You settle the schema. Then you graduate: that work is done, and now the real work begins on top of it.

A barre is not setup. A principal dancer at thirty-five does the same plié as a six-year-old in her first class, every day, forever, and the difference between them is not that one has moved past it. The difference is everything the fundamental is carrying by then.

This is why so much enterprise software degrades in a specific way. It doesn't break. It drifts. The schema stops describing the business. The design system becomes a folder nobody opens. The tests pass and mean nothing. Each of those is a fundamental that was treated as a phase, completed, and left behind, while the artistry kept getting built on top of it.

You can see this from outside the building. A product that has stopped returning to its fundamental looks fine in a screenshot and feels wrong in the hand.

And the fundamental is not always an artifact. It can be understanding: of the customer, of the domain, and of why the last attempt failed. It can be technical expertise. It can be curiosity, which is the easiest one to mistake for a phase, because curiosity is what everyone has in month one and almost nobody has in year three. Whatever it is, the test is the same. Do you return to it, or did you finish it?

Both halves fail, and they fail differently

Here is the part that is hardest to hold onto:

Without the artistry, the technical skill is boring to watch, uncompelling, a bag of tricks. Without the technical skill, the artistry is clunky, embarrassing, unrefined, undisciplined.

Both of those are failures. Not one failure and one disappointment. Two failures, of equal standing.

Software culture does not believe this. It has an enormous tolerance for the first kind and almost none for the second. A product that works and is unpleasant gets shipped, defended, and called pragmatic. A product that is beautiful and hollow gets called a demo, and the word is an insult.

The asymmetry is a tell. It means we think function is the real thing and craft is the finish: the paint, applied at the end, by someone else. And once you believe that, you have already lost the ability to see the first failure at all, because a working ugly thing satisfies the only test you're running.

The four strands

The working form of the law is four strands, and none of them is a tiebreaker for the others:

implementation sound · function real · craft disciplined · beautiful

A pretty screen over a dead verb is a technique failure equal to an ugly working one.

That sentence does more work than it looks like. It refuses the trade in both directions. You cannot buy your way out of a dead verb with a beautiful surface, and you cannot buy your way out of an ugly surface by pointing at the verb. There is no exchange rate between the strands. The piece is at bar or it isn't.

Why organizations can't hold it

The law is easy to agree with and hard to run, and the reason is structural.

Most product organizations split these strands across people who report to different leaders and are measured on different things. Engineering owns sound and real. Design owns disciplined and beautiful. Each does their half well. Nobody owns whether the thing, assembled, is at bar, because that question doesn't map to a role, so it doesn't map to a review.

What fills the gap is a sequence. Design hands over a comp, engineering builds what's feasible, and the difference between the two gets absorbed quietly as the cost of shipping. Nobody decides to ship something unfinished. It's just that the only person who could have seen it whole didn't exist.

This is why I don't think of craft as a design function. It's a leadership function, and it's mostly about what you're willing to call done.

Where I've seen it hold

It is a Tesla, a car where the engineering and the object are not two projects.

It is fine dining that walks the tightrope of incredible but not pretentious, which is a harder discipline than either extreme. Anyone can be impressive. Anyone can be unfussy. Being both, at once, with nothing showing, is the whole job.

And it is what I'm building now. At DEMMANND the fundamental we never leave is the graph and the loop. Every signal that returns to the graph compounds, and nothing in the product is allowed to break that return. The barre is the unglamorous part: gates, baselines, and receipts, the discipline that runs before anything is called finished. The artistry is the face, the voice, and the experience of ease. An organ with only one half is not at bar.

The tightrope is the constraint that keeps the artistry honest. Incredible but never pretentious. The moment craft starts performing itself, whether that is the animation announcing how much care went into it or the interface that wants credit, it has stopped being technique and become decoration. Real artistry disappears into the thing. You feel it and can't point at it.

The claim

Technique and artistry are one discipline. Not a balance to strike, not a tension to manage, not two teams meeting in the middle. One.

Every class starts at the barre. Nobody graduates from the fundamental. You train it as hard after you have mastered it as you did before, and the reason you can change everything above it is that the thing underneath is kept pristine.