A pattern for reading the spreadsheet as the specification

A pattern earns its keep by being cheaper to apply than to argue about. This one has survived laboratory sample tracking and four other sectors that share none of the same vocabulary, which usually means the shape is real and not a coincidence.

The spreadsheet somebody maintains by hand is the most accurate specification in the building. It has no budget, no committee and no aspirations. It describes what the work actually requires, which is more than the requirements document manages.

WHY IT IS MORE HONEST

A requirements document describes what people believe should happen. A spreadsheet describes what they do to get through the week. When those disagree, the spreadsheet is right, because it's under daily pressure from reality and the document isn't.

It also survives selection. Every column in it exists because someone needed it badly enough to type it in repeatedly. Nothing in it is speculative, which is not something you can say about any feature list.

HOW TO READ ONE

Start with the columns nobody can explain the name of. Those are usually where two concepts got fused because the system forced a choice. Then look for the colour coding, which is almost always an undocumented state machine. Three shades of yellow means three states your model needs.

Then find the comments. Free-text notes are where the exceptions live, and the exceptions are the actual domain. Read forty of them in a row and you'll have a better model than any workshop produces.

It paid for itself the first time a batch was reported before its confirmatory run had finished. Because the structure was already there, recovery was a query instead of an investigation, and lab managers heard it from the system rather than from a customer.

REPLACE THE JOB, NOT THE FILE

The instinct is to build the spreadsheet as software, which produces a worse spreadsheet with a login page. The point isn't to reproduce the file, it's to remove the reason it exists, usually a state the real system can't represent or a handoff it can't see.

Fix that and the file stops being updated on its own. That's the outcome to aim for. Nobody needs to be told to abandon a workaround once the workaround stops being necessary.

At an environmental testing lab it turned a recurring escalation into an ordinary state the system could describe. Around 20,000 samples a month went through without a single manual reconciliation, which hadn't been true of any quarter before it.

WHERE IT GOES WRONG

• Banning the spreadsheet before the system can represent what it was tracking.
• Building the spreadsheet as software, and shipping a worse spreadsheet with authentication.
• Ignoring the colour coding, which was the state machine nobody wrote down.
• Reading the requirements document and not the forty free-text notes that describe the real exceptions.

Read the spreadsheet before the requirements. Then remove the reason it exists.

WHEN TO REACH FOR IT

It's cheap on day one and expensive to retrofit, which makes it a default rather than a decision. We put it in the first commit and haven't regretted it yet.