Requirements first, code second: a systems thinker’s habit

I write requirements before I write code. Not always a formal document — sometimes it is a page in a notebook, sometimes it is a thread in Linear — but the shape is the same: what are we actually trying to make true, for whom, and how will we know.

Why this is cheaper than the alternative

The cheapest place to disagree is on a page. The cheapest place to be wrong is on a page. The cheapest place to discover that the real problem is a data problem, not a modelling problem, is on a page. By the time disagreement reaches a pull request, it has already cost compute, review time, and momentum.

It is especially valuable across domains

My work spans finance, biology, urban systems, and geospatial intelligence. Each of those domains has its own assumed vocabulary and its own definition of “done”. A short requirements pass forces those assumptions into the open before they leak into the implementation, and gives non-engineering stakeholders something concrete to push back on.

A requirement is a falsifiable claim

The best requirements read like falsifiable claims about the finished system: “the dashboard returns a scored polygon in under 500 ms for a payload up to 10 MB.” That is testable. That is shippable. Vague aspirations — “the system should be performant” — are neither.