Inner coherence vs usefulness

Around 1900, when modernist art was emerging, art historians talked about the significance of art in context: the painting is not complete without the beholder.

Before that, the beholder wasn’t so important. People looked for art to express some universal truth through beauty.

Before cultures and artists considered the role of the beholder, they made art that didn’t need you. The art has inner coherence.

A lot of software development aims for inner coherence. Code that is elegant, that is well-designed and admirable on its own.

I used to like that, too. But now I want to think about code only in context. Software is incomplete without use.

If my code is full of feature flags and deprecated fields for backwards compatibility, that’s a sign that it is used. The history of the software is right there to see. I don’t want to hide that history; I want to make it very clear so that I can work within it.

My job isn’t to change code, it’s to change systems, so that we can adapt and grow increasingly useful instead of obsolete.

This old painting may be beautiful, but it doesn’t affect me the way Gustav Klimt’s work does. (some drawings, NSFW) He was one of the early modernist artists to speak of contextual, rather than universal, truths.

Within our teams, contextual truths have the most power. In my software, it’s a contextual coherence of its larger system that I care about.