Cheaper
Letting the First Version Be a Bad Version
A rough page published today is worth more than a good page published in six weeks, and it gets better for free once people start using it.
What nobody wrote down here, and what it cost
What the deploy order is
Guessed, then corrected
Four lines would have ended it
How the staging database is rebuilt
Asked seven times
The answer was four minutes long every time
two things nobody wrote down · 16 occasions it cost somebody something
Two things, sixteen occasions, and both answers were short.
Documentation is easier to defend when the team can connect it to measurable time saved; productivity monitoring for distributed teams provides an operational reference for that conversation.
Teams can compare this approach with the established material available from Medium.
Four pages, and the weeks somebody opened each, against when each was published
Published rough in week two
Nine weeks of use, and it was corrected twice by readers
Published after one polish in week five
Five weeks of use; the polish delayed it by three weeks
Held until it felt right, published in week sixteen
Three weeks of use; fourteen weeks of its life spent unpublished
Never published
Finished in week six, still unpublished, question asked five more times
four documents · 17 weeks in which somebody opened one of them · the longest wait between writing and a reading was 33 weeks · one never read at all
Four pages, seventeen weeks in which somebody opened one of them, and one never read at all. The rough page was used in nine separate weeks and was improved by its readers. The careful one was unavailable for fourteen weeks of the period it covers. One team's own three quarters.
The instinct to publish only finished work is sound in most contexts and wrong here, for a reason specific to documentation: an unpublished page helps nobody, and a published page improves by itself.
The second half is the part people do not believe until they have seen it.
What readers do to a rough page
They find the errors, which the author could not.
They ask the questions it does not answer, which is a list of what to add.
Where the tool allows, they fix it, and the corrections are usually better aimed than anything the author would have done.
None of that happens to an unpublished page, which is why a draft sat on for six weeks is not six weeks closer to being good. It is six weeks older.
The cost of waiting, counted
The panel above covers three quarters. The page published rough in week two was used in nine separate weeks. The careful version of comparable material was published in week sixteen and was used in three.
The difference is not quality. It is availability, and the thirteen weeks of unavailability are a cost that nobody counts because it is another absence.
What rough should actually mean
Not careless. Rough means unfinished in the places that do not matter:
- Not tidied, not reordered, not formatted beyond basic legibility.
- Missing the sections nobody asked for.
- Gaps marked rather than filled.
- Pasted output instead of described output.
It should still be accurate in what it says, and it should say what it does not cover. Those two are the floor and they take no extra time.
The label that makes it comfortable
One line, which does the same work as the lines in earlier pages:
Rough notes, written 14 March. Incomplete and probably wrong in places. Fix it or ask.
An author who writes that has made no claim they cannot defend. A reader who sees it knows how to read what follows. And a colleague who spots an error has been invited to correct it rather than to raise it.
That line is the difference between publishing in week two and publishing in week sixteen.
Why the careful version is tempting
Because publishing something scrappy feels like a statement about the author's standards, and the first instance is genuinely uncomfortable.
It helps to notice what the comparison actually is. The choice is not between a rough page and a good page; it is between a rough page and no page, because the good page has, on the evidence of most teams, a substantial chance of never arriving.
The drawer problem
The fourth row is the one worth looking at hardest: a page finished in week six and never published, while the question it answers was asked five more times.
This is more common than anybody admits. Most people who write have one or two of these, complete, waiting for a final pass that will not happen because there is no deadline and no prompt.
The instruction is blunt: publish it today, with the line above at the top. The final pass was never going to happen and the page is already better than nothing.
What rough is allowed to mean
Rough is not careless, and the distinction decides whether publishing early helps or hurts.
| Rough means | Rough does not mean |
|---|---|
| Not tidied or reordered | Inaccurate in what it does say |
| Missing sections nobody asked for | Silent about what it omits |
| Gaps marked rather than filled | Untested instructions presented as tested |
| Pasted output instead of described output | No date and no author |
The right-hand column is the floor and costs nothing to clear. A page that is accurate, dated and honest about its gaps can be as scruffy as its author likes.
When rough is not acceptable
Anything a person will follow alone under pressure — an incident runbook, a procedure run at three in the morning — should be complete in its failure cases, because the reader has no capacity to interpret a gap.
Anything external, where the audience is a customer or a regulator.
Everything else is internal, read by colleagues who can ask, and is better rough and available than good and absent.
Correcting somebody else's rough page
A page published rough is an invitation, and the invitation only works if the first few corrections go well.
The habit that matters is fixing rather than reporting. Somebody who spots an error and edits it has spent twenty seconds; somebody who messages the author about it has spent the same twenty seconds and created a task for a second person.
The corresponding habit on the author's side is saying thanks rather than apologising. An apology makes the next correction feel like an accusation, and within a few rounds people stop correcting and start quietly working around the errors instead — which is the state most stale documentation is in.