Bug

Software has behaved incorrectly since the first day anyone wrote any. What didn't exist was a shared name for that class of problem and a way of counting it one item at a time.

Without the name, conversations stalled in a predictable place. A customer writes in to say that payment isn't working. Support pastes that sentence into the engineering channel. An engineer tries a payment in their own browser and it goes through. The thread ends there, because nothing anywhere records which card was used, which screen it happened on, or whether an error message appeared. Three more reports arrive that week and all three stop at the same point.

Mixing was the other half of the problem. "This button doesn't respond," "this button would be better on the right," and "this feature doesn't exist yet" all land as adjacent lines in one channel. The first is a broken promise. The other two are requests to build something new. Different in kind, identical in format, and impossible to prioritize against each other.

The word bug took hold as the thing that separates those. You write down what the behavior was supposed to be, and only when the actual behavior differs from that does it get called a bug. So the term always drags a standard along with it. Without one, two people look at the same screen and one calls it broken while the other says it was always meant to work that way.

It starts by turning into a record the moment someone notices it. Something that exists only in a chat message or in one person's memory isn't yet in a state anyone can act on. A single record carries five things.

1. A one-line title. Not "payment fails" but something like "payments with foreign-issued cards hang at the authorization step," so the title alone says where and what.
2. Reproduction steps — the numbered sequence that makes the behavior happen again. Without them whoever picks it up spends the first hour reconstructing the situation.
3. Expected behavior and actual behavior, written as two lines side by side. Those two lines are what decide whether this is a defect at all or simply how the thing was designed.
4. Environment: browser, operating system, account type, and time. A large share of defects appear only under specific conditions, so this line is what narrows the search.
5. Severity — how much the defect affects the service. It's attached so that a blocked checkout and a label misaligned by a few pixels never sit on the same line as equals.

Once the record exists it follows a set path. Someone confirms it reproduces, severity and priority get assigned, an owner traces the cause, the fix goes in, a regression test checks that nothing adjacent broke, and the record closes. Skip that last step and you close records that fixed one thing while breaking another.

Not every record ends in a fix. Some close as not reproducible, some close because the fix isn't worth what it costs, and some close because the behavior turns out to be intentional. All three are legitimate endings, and writing down which one applied saves time the next time the same report arrives. If the same behavior comes back later, the old record gets reopened instead of a new one being filed.

It sits in the middle of quality assurance (QA). Whoever checks a release writes down everything they find, and the decision to ship or hold gets made against that list. A threshold is normally agreed in advance: fix anything above a given severity, carry the rest into the next cycle.

On the support side, the moment a ticket becomes a bug is the one that matters. Most incoming questions come from not knowing how something works, and only a fraction are real defects. When support collects reproduction steps before handing the report over, the time engineering spends deciding which kind it is drops sharply.

Planning reserves room for it too. Committing a fixed share of each cycle to fixes is the common approach. Fill cycles with new features only and the list accumulates quietly until it forces a reckoning, at which point weeks go to nothing but repairs. The share varies by team and runs higher on older products, since more accumulated code means more places that need attention.

"Is this a bug, or is it supposed to work that way?"

Asking what the expected behavior was actually defined to be.

"I closed it as not reproducible and then the same report came in again."

Likely a defect that appears only under certain conditions, so more environment detail is needed.

"We're fixing the high ones for this release and carrying the rest."

A decision to ship against a threshold rather than emptying the list.

At Pagedeck, Sofia doesn't forward customer reports as they arrive. She asks which screen it happened on, what was clicked, whether an error appeared, and whether another browser behaves the same way, then writes that down and passes it along. That single round of follow-up questions cuts half a day off engineering's triage.

What comes across goes to Theo, who starts by confirming it reproduces. If it does, severity goes on, the high ones get handled that week, and the rest accumulate on the list. Mia pulls a set share off that list into the plan at the start of each cycle.

The most common belief is that every bug has to be fixed. Leaving a defect in place looks like giving up on quality. But fixes cost something, and fixes introduce new defects of their own. Touching the payment flow to correct a layout glitch that appears twice a year under narrow conditions is a bad trade. Without that judgment the list grows into the hundreds, and the genuinely urgent items become invisible inside it.

Reading bug count as a quality score is the other one. Fewer reports, better product — the inference is natural. But the number of reports depends as much on how heavily the product is used and how easy reporting is as on the state of the code. Double the users and reports double. Add a report button to the screen and they rise again. Start evaluating people on that number and the team moves toward filing fewer records rather than fixing more software, and then nobody knows how much is broken.