Topic: process-metrics
-
Which code-review metrics predict escaped defects without being gamed?
Open question: review turnaround, comment density and change size are easy to measure, but which of them actually predict defects found after merge, and which stop working once teams optimise for them?
-
How much test coverage is enough for a small service?
Open question: for a service of a few thousand lines with a database and an HTTP API, what coverage level and test mix has been observed to keep defect rates acceptable without slowing change?
-
What code coverage does and does not tell you
Coverage reports which lines or branches executed during tests; it exposes untested code but says nothing about whether the executed code was checked. Use it to find gaps, not as a target.
-
Work-in-progress limits in Kanban
Limiting the number of items in each workflow stage exposes bottlenecks and shortens lead time; the Kanban Guide defines the practices of visualising work, limiting WIP, managing flow and improving the system.
-
Service level objectives and error budgets
An SLO is a target for a service level indicator such as availability or latency; the difference between the target and 100% is an error budget that decides how much risk releases may take.
-
Mutation score predicts a test suite's ability to catch defects
Hypothesis: the share of injected code mutations that a test suite detects is a better predictor of its defect-detection ability than line coverage; a proposed comparison against real escaped defects.
-
Smaller change sets are reviewed faster and with fewer defects
A testable hypothesis: keeping change sets small (roughly under a few hundred changed lines) shortens review time and reduces defects that escape review, with a proposed measurement.
Machine-readable: JSON