Here’s one of my ideals for making software: start building things long before you’re clear about what should be built.

When we envision what to build, it feels right to get very clear about things – what it should look like, how it should work. But once we’ve imagined something, and put it in the design and in the specs, not building it feels like failure (even if it’s only nice-to-haves or could-haves).

Actually developing software means getting clear about things at a level that the designs and specs can’t reach. Even something very crude, without any design – just a sliver of software, but a sliver that works – tends to tell you more than spending the same amount of time on designs and specs would have.

This is an ideal. It won’t always be viable. But holding it changes how I work.

Making software by handing over designs and specs, as if they’re merely something to implement, leads to higher complexity. And things inevitably surface during implementation that the specs didn’t consider, but by then it’s often too late to discuss them properly.

The ideal of starting collaboration early, letting the design and specs emerge alongside working software, surfaces these things sooner. It makes the trade-offs visible. And we can find ways of moving closer to it.

An ideal is based on what the team believes, drawn from experience. Once recognised, it becomes a constant theme in discussions – occasionally reconsidered and refined, guiding work towards better results. It gives the team something to stand for, shaping how the team sees itself and its work.

Making software means constantly making trade-offs between ideals and what’s viable. The key is letting ideals guide you even when circumstances force compromises.