↓ Skip to main content

2 min read

The importance of writing your own specs

If you can't explain what you want, how can an agent be expected to build it?

In my first career, civil engineering, we were trying to build quite a funky split-dome shape - a bit like a chocolate orange - with arched reinforced concrete beams supporting timber beneath a zinc roof.

Where the arched beams met, meshing the reinforcement with other intersecting beams was far from easy. The heavy reinforcing either clashed with its neighbour or bunched together making it nigh-impossible to pour concrete around them in a way that was acceptable for a solid engineering connection.

We contacted the design engineer who sent us a new set but they were wrong too. So was the third. They came down to site so that they could see the problem for themselves.

“The problem is that it’s quite hard to draw” confessed the young design engineer.

My boss replied “If you can’t even draw it how on earth are we expected to build it ?”

Many years later I find myself in software teaching Spec Driven Development to software engineers.

At a recent standup one of the more junior engineers in the team - also very new to this way of working - struggled to explain how two components of a system she’d coded interacted with each other. The system I’d designed routed messages through a controller, with certain messages triggering an insert into a DynamoDB table. She was unsure whether the table triggered the controller or the controller wrote to the table. We took it off line.

After the standup I walked through it with her and it became clear that she hadn’t really understood requirements, had started to write a bit of the specification then let go allowing Claude to finish it for her.

I’ve never forgotten my bosses comment so I’ve always insisted that engineers working with Spec Driven Development never let Claude write the specs - it can help and can point out where there are holes - but I expect the specification to be a narrative written by a human . “If you can’t explain what you want then how can an agent be expected to build it ?”

As a once civil engineer I’ve always been frustrated how software engineers often start something without really knowing what finished looks like - working it out for themselves as they go along. Spec driven stops that. It’s hard when you first do it but it makes you a real engineer not code craftsman.

More field notes

  1. Musk: the film nobody got to seeAlex Gibney's Musk lasted two weeks in US cinemas and got written off as a flop. I'm not sure anyone really had the chance to see it.Read the note →
  2. Hedgehogs, Foxes and FoundersIsaiah Berlin split thinkers into hedgehogs and foxes. Founders assume they have to pick one. The ones we've seen succeed hold both - just not about the same thing.Read the note →
  3. Building an MVP: A Worked ExampleA real founder, a long feature wishlist, and a 'TripAdvisor for dog owners' - here's how we turned it into a scoped, buildable MVP.Read the note →
All field notes →

Working through something similar?

If you're trying to figure out what's real and what's noise, we're happy to talk it through.

Talk to us →