Defects per Code Engineer

Tracking exactly who created each defect, because accountability starts with attribution!

Defects per Code Engineer is the metric that transforms quality from an abstract aspiration into a personal responsibility. For each Code Engineer, the framework tracks the number of defects they create and attributes each defect directly to the individual whose code introduced it. This attribution is not punitive – it is informational. The information simply happens to be shared with the Tribunal, displayed on the team dashboard, factored into performance reviews, and used to determine Shore Leave eligibility. But the metric itself is neutral. It is just a number.

The attribution process is managed by the Development Integrity Assurance Team (DIAT), who use git blame analysis to trace every defect to its originating commit and, by extension, its originating engineer. When a defect spans multiple commits by multiple engineers, the defect is attributed to all contributing engineers at full weight – there is no fractional attribution in SADMF, because shared blame is indistinguishable from diluted accountability. If three engineers contributed code to a defective feature, each engineer receives one full defect on their record. This ensures that engineers are incentivized to avoid collaborating on complex features, which has the added benefit of reinforcing Continuous Isolation principles.

The metric directly supports the principle of Build Quality In. SADMF interprets this principle literally: quality is built in by identifying and eliminating the sources of defects. Since defects are created by people, eliminating the source of defects means addressing the people who create them. Engineers whose defect counts exceed the fleet median are placed on a Defect Reduction Plan, which requires them to attend additional Code Inspection sessions as observers (not participants) and to write a Root Cause Analysis document for each defect using the Comprehensive Documentation Assurance Protocol template. Engineers whose defect counts remain elevated after two consecutive Convoys are escalated to PeopleWare HRaaS for automated corrective action.

The Fail Fast principle also intersects with this metric, though SADMF interprets “fail fast” not as a development practice but as a personnel management strategy. The faster the organization identifies engineers who produce defects, the faster those engineers can be coached, retrained, or reassigned. The defects-per-engineer metric enables this rapid identification by providing real-time data to the Chief Signals Officer, who monitors defect trends across the fleet and alerts the Commodore when any individual’s defect trajectory crosses a predefined threshold. Speed of detection is the key – every day a high-defect engineer continues writing code is a day of compounding quality debt.

It is essential that Defects per Code Engineer is tracked alongside Lines of Code per Code Engineer to prevent gaming. An engineer who produces zero defects and zero lines of code has not achieved quality – they have achieved absence. The balanced scorecard approach ensures that Code Engineers are held accountable for both output and quality, creating the kind of productive tension that SADMF considers essential for Continuous Learning. Engineers who feel this tension describes their daily experience are experiencing the framework working as intended.

See Also