Dates That Are Not Yours

Building in a regulated market has changed how I think about roadmaps, and the change turned out to be more fundamental than I expected.

In most software, dates are negotiable. You scope, you slip, you ship the smaller thing. The date is an artefact of planning, and planning is yours to redo. Every process I had internalised — agile, continuous delivery, the whole apparatus — takes this as a premise. Deadlines are inputs you control.

In a regulated market there are dates on the calendar that are not yours and do not move. A statutory provision takes effect when it takes effect. The date does not care about your sprint capacity, your hiring pipeline, or how the quarter went.

Two things follow, and they pull in opposite directions.

Planning inverts

You plan backwards from the date rather than forwards from your velocity.

This is genuinely clarifying, and I did not anticipate how much. A great deal of prioritisation argument simply evaporates when the deadline is external. Nobody negotiates with a statute. The conversation shifts from "what should we build next" to "what has a lead time longer than the time remaining", which is a far more tractable question.

The work that surfaces first is the work with long lead times and external dependencies — anything involving physical production, third-party requalification, contractual amendment. The things you cannot compress by working harder.

Precision becomes a load-bearing property

The second consequence is subtler and much easier to get wrong.

A scheduled requirement is not a current one, and the pressure to blur that line is constant. Urgency is persuasive. A future rule described in the present tense sounds more compelling, and there is always someone for whom that framing is convenient.

Giving in to it makes you unreliable at exactly the moment people most need you to be precise — and it is expensive for them in both directions. Treat a scheduled provision as current, and operators pull spend forward for no benefit: label runs, packaging, inventory commitments, all incurred early against a requirement that does not yet bind. Treat it as optional, and they run out of runway against a date nobody can negotiate.

Both errors come from the same root: collapsing "scheduled" and "in effect" into a single idea because the distinction is inconvenient to hold.

Where it ends up

So we hold the line in the data model rather than in editorial judgement, which is the only place it survives contact with deadline pressure. Scheduled provisions are stored as scheduled and rendered as future requirements everywhere they appear. There is no path through the system that lets a future date be described as a present obligation, because there is no field that would permit it.

That constraint has cost us copy that would have performed better. I have come around to thinking that is the point. If your accuracy depends on everyone remembering to be careful, you will be accurate right up until the week you are busy.