This week we shipped release 1.3 of Handee, the compliance layer we build for multi-site facility operations. The feature list is on the Handee site if you want it.
This post is about the other half of the release: the things we took out.
We tell prospective clients that we measure one number, the time recovered on the work they hand us. A promise like that is only worth anything if we are equally disciplined about what we refuse to claim. Here are three from a single release.
A line we cut from our own release notes
Our changelog said we had added on-time completion tracking. The code is real. The service calculates it, the database query behind it is tested and works.
It appears on no screen. Nobody using Handee can currently see it.
So it came out of the announcement. Capability that exists in a repository and capability a customer can use are different things, and only one of them is worth telling you about. The changelog line was written by someone who knew the code had landed, which is exactly how this kind of overstatement happens: not by lying, but by describing the work instead of the result.
A number we would not publish
Release 1.3 also published Handee's service levels: first response targets by priority, an availability target, data residency, breach notification timelines. Procurement teams ask for this document constantly, and having it ready is worth real money in a sales cycle.
What is not on it is a recovery time objective.
We do not have one we would defend under scrutiny, and inventing a figure that reads well would have made the document better to sell with and less true. The page says so directly. It also says that everything on it is a target rather than a contractual guarantee, and that no service credits attach to any of it. We would rather publish numbers we consistently beat than numbers we owe money for missing.
Measurement before claims
The largest part of 1.3 was analytics: where work orders actually sit, how long each stage really takes, and what is ageing past the point where somebody ought to care.
We built that before having a customer to run it on, deliberately. You cannot report time recovered on a workflow you never instrumented. Measurement is not a reporting feature bolted on at the end once the interesting work is done. It is the thing that makes the promise checkable, so it goes in early or the promise is decoration.
The bug our tests could not see
The service level documents shipped. Then every page that renders them returned an error in production.
The cause was ordinary. Our build configuration excluded the documentation directory. Every test passed, because the tests read those files from the working copy on disk, where they sat exactly as expected. The tests were checking that the documents were correct. Nothing was checking that the documents were present in the thing we actually deployed.
We fixed it the same day and added a test that asserts the build context itself. That class of bug, where the test and the deployed artefact disagree about what exists, is one we now check for by default rather than discover.
We mention it because a company that publishes an incident policy should probably say what happened the first time it had an incident.
The point
None of this is dramatic. It is the ordinary discipline of not saying more than you can show, applied to a small release by a small team. It is also the whole basis on which we ask anyone to trust us with their work.
If something in your organisation is quietly eating a day a week, and you want it assessed by people who will tell you honestly whether it can be fixed, that is the conversation we like having.