Reporting Status Honestly When Software Is Half Finished

Status updates are where software projects quietly go wrong. Nobody lies, exactly. But "the payment feature is done" turns out to mean the code is written and nobody has tried a real payment. "The migration worked" turns out to mean the import finished and nobody compared the pages. "Tests pass" turns out to mean the fast checks passed and the full suite has not run.

Each of those statements rounds up. The rounding feels harmless until a customer finds the gap. We try hard not to round up, and we have a few habits that help.

Name the stage precisely

We describe progress in stages that mean specific things:

1. Built: the code or content exists and has been reviewed.
2. Checked: automated checks ran, with the mode and results stated.
3. Released: the change is live in production, with the release identified.
4. Accepted in the browser: a person used it, signed in, at the relevant sizes.
5. Accepted with providers or money: outside services and real transactions behaved as expected, when that applies.

A status update says which stages are complete. "Built and released, browser check pending" is useful. "Done" is not.

Say what failed

When a test fails, the status says so and includes the result. When a check could not run, for example because a service was unavailable, the status says it did not run and why. A list of only successes invites the reader to assume nothing else happened.

Say what was skipped

Skipped steps are easy to omit from an update, especially when they were skipped for good reasons. We name them anyway: "fast pipeline mode, full suite not run," "phone check not done," "real purchase not tested because it requires approval." Readers can then decide whether the skip matters for their purpose.

Do not predict results

It is tempting to describe the outcome of something still in progress, such as a pipeline that is running or a helper still working. We do not. Until a result has been observed, the honest status is "running" or "pending." Predicting success saves a few minutes and costs credibility the first time the prediction is wrong.

Keep holds visible

Some features are complete in code but deliberately held: waiting for an approval, a provider decision or an owner's review. Status updates keep those holds visible, with what is needed to release them. A held feature described as "done" invites someone to switch it on prematurely.

Evidence beats adjectives

Words like "solid," "robust" and "fully working" carry little information. Evidence carries a lot: the release identifier, the number of checks that passed, the screenshots from the phone check, the record that shows a payment was reconciled. We prefer status updates that point to evidence over updates that describe confidence. A reader can verify evidence; they can only trust adjectives.

Counts should be complete

When a status includes counts, such as pages checked or items finished, it should also say the total and what is left. "Twelve pages checked" means little without "of seventeen." A complete count, with the remaining items listed, turns a status update into a plan.

Plain language for customers

Customer-facing status needs the same honesty in simpler words. If a feature is not available yet, the product says so plainly. If something is limited, the limit is stated. We never describe internal stages to customers, as explained in why customers never see our internal phase numbers, but we never pretend unavailable features exist either.

Honest status is a kindness

It can feel uncomfortable to report a gap, especially when someone is waiting. But an honest update lets people plan, decide and help. An optimistic one shifts the discomfort to later, usually to a worse moment, often to a customer. Our handoff notes exist largely to make honest status easy to write and easy to read.

A habit for any team

If you lead a team, try asking for status in stages: what is built, what is checked, what is live, what is accepted and what is held. The answers will be more useful than "on track," and problems will surface while they are still small.

Frequently asked questions

How should I report the status of a software feature?

State which stages are complete, such as built, tested, released and accepted, and name anything that failed, was skipped or is on hold.

Why not report a feature as done when the code is written?

Written code may not be tested, released or working for users. Reporting stages separately avoids surprises.

Is it bad to report that a test failed?

No. Reporting failures with results lets people make good decisions and builds trust in every other status you report.