A missing translation key is not an error anywhere, which is why users see them
Forty-seven error codes the API could emit had no copy in the portal, so users read raw key strings. Nothing in the stack treats that as a failure.
Topic
Product Behaviour
What the software actually does to the person using it, which is not what the spec said.
20 articles
About this topic
These are the failures that never appear in a log. A click that writes to a row nobody reads. A notification that is generated correctly and delivered to nobody. A status column that was true on the day it was written and has not been looked at since. A screen that reports a thousand missing pricing rules when thirty-three are real. Nothing errors, and the person using it slowly stops trusting the system.
The common cause is that the software was organised around how the data is stored rather than around the process somebody is trying to complete — filing cabinets, when the user is running a job from start to finish. The fix is rarely more features. It is usually noticing that the last step of a real workflow has no screen, because the requirement stopped where the data model did.
The status column said active, and nothing had looked at it since the day it was written
A credential row carried both an expiry date and a status label. Only the date changes meaning as time passes, so every query had to distrust the label.
An endpoint nobody can reach is not a feature, and a search box that does not search is worse
A field-force product where a rep could not take an order on the phone. The API was complete, the module was marked done, and the flow did not exist on any client.
Every question was correct and the whole set was broken
A hundred and fifty multiple-choice questions all had the answer in the first position. Each one was right. The distribution was the defect.
Fifty-seven screens do not divide into seven workers without a foundation
Every contract bug in the project so far had been between contributors rather than inside one, so the rebuild started by making the seams mechanical.
The notifications were correct, and every one of them went to nobody
Nine send points, each carefully guarded, firing into an empty token table because the app had never called either registration endpoint.
The dashboard guessed whether the number was a percentage, and turned 1% into 100%
A helper decided a stored value was a fraction if it was between zero and one. The one organisation that most needed the alarm got a perfect score instead.
A credential expiring today was in neither the expiring list nor the expired list
Four places asked "is this about to run out" and four expressions answered. Two excluded today, one included it, and one forgot to exclude revoked records.
The quiz score was a fine proxy for reading, except on the lessons that mattered
A proxy metric that works on average can fail completely on one part of its domain, and the part it fails on is often the part you added it for.
The tables existed, the columns existed, and not one route served them
Seventy-five endpoints, all parent-facing. The child's half of the product had a schema, a plan and a design, and no server to talk to.
The lesson needed two facts to be true, and the screen only asked for one
Publish was a button. Assign was an item in an overflow menu on another screen. The child's tablet needed both, and said nothing when it had one.
The click that did nothing was writing to a row nobody reads
An unordered single-row lookup on a non-unique key is not a bug that throws. It is a bug where the user presses a button and the screen ignores them.
A status only your own app can change will never be true for long
A dashboard tile read 86 open jobs for one driver. Three were open. The other 83 had ended in ways the app was never told about.
Availability is a question about a date, and the picker was answering about today
A salesperson pitching a campaign that starts next quarter does not care what is free this morning. Availability needs a date argument, not a boolean column.
The app was organised like filing cabinets and the people using it were running a process
Nine modules named after data types. One job — book a hoarding and bill for it — spread across three of them. That is why software feels scattered.
The receivables card said zero and the database held forty-five unpaid invoices
Fixed-precision money columns come back from the driver as strings. Add them with the wrong operator and the total is silently not a number.
The booking rule that blocked eight paying clients, and why it was a bug and not a missing feature
A digital screen loops six to eight adverts at once. The system allowed one. That is a correctness defect, and it should be sequenced like one.
You finish the booking and the software just stops
The data was a chain and the interface was a set of dead ends. No record linked forward to the one it produced, so every step meant going back to a menu.
The thing you sell is not the thing on the map
A hoarding is a location. What a client buys is a surface, for a window, at a rate. Conflating the two puts the overlap check on the wrong row.
Trips completed this month" actually meant "assigned this month
A driver dashboard counted work by a row's updated timestamp. The timestamp was stamped on insert and had never moved on any of 221 rows.