Lines of Code per Code Engineer

The definitive measure of developer productivity – because more lines means more value!
Tags:
SADMF Certified Productivity Metric • Class I • Fleet-Wide Mandatory
Lines of Code
per Code Engineer
LOC_SCORE = ∑(committed_lines) ÷ code_engineers   —   all line types included
Owner Role
Commodore
Cadence
Per Convoy
Reported By
SMT Automated
1 Story Point =
~147 LOC
How It Works — Calculation Sequence
01
Commit Scan
The Source Management Team (SMT) runs an automated scan of all commits to the Fractal-based Development branching structure at Convoy end. Every committed line is captured.
02
Inclusive Line Count
All line types are tallied without exception: production code, comments, blank lines, and configuration files. Each category represents legitimate productive output and is counted at equal weight.
03
Per-Engineer Attribution
Total LOC is divided by the number of Code Engineers in the fleet. Individual scorecards are produced and routed to the DOUCHE for review. Note: Unit Testers are excluded from this calculation entirely.
04
Story Point Conversion
Fleet LOC totals are converted to story points at the official rate (1 story point ≈ 147 LOC, adjusted for language complexity coefficient) and fed into the 8-quarter commitment planning process.
05
Consequence Routing
Engineers below fleet median are placed on a Performance Improvement Plan. Engineers above median receive recognition at Shore Leave. Persistent underperformers are escalated to the Tribunal. PeopleWare HRaaS automates threshold-based HR actions.
What Good Looks Like — Fleet Excellence Standard
A high-performing Code Engineer consistently produces 600–900+ LOC per Convoy day, regardless of task complexity, refactoring necessity, or the existence of prior art that could be reused.
  • Comments and blank lines are included — verbose, well-spaced code is thorough code.
  • Configuration files count — infrastructure investment is visible and rewarded.
  • Refactoring that reduces line count is a red flag requiring Tribunal review.
  • Reusing existing library code instead of writing new lines is an underreported anti-pattern.
  • The mathematically ideal engineer produces maximum LOC and minimum defects simultaneously — any trade-off indicates a coaching gap.

Lines of Code (LOC) per Code Engineer is the foundational productivity metric of the Scaled Agile DevOps Maturity Framework. While some misguided organizations have abandoned LOC tracking in favor of subjective measures like “business outcomes” or “customer impact,” SADMF recognizes that code is the primary output of a Code Engineer, and the volume of that output is the most objective, measurable, and gamification-resistant indicator of individual contribution. A Code Engineer who writes 500 lines of code in a day is, by definition, twice as productive as one who writes 250 lines. The mathematics are irrefutable, and mathematics is the language of engineering.

The LOC metric serves a critical balancing function within the SADMF metrics ecosystem. Because the framework also tracks Defects per Code Engineer, there is a theoretical risk that Code Engineers might attempt to reduce their defect count by writing less code. This perverse incentive must be neutralized. By measuring LOC alongside defects, the Commodore can identify engineers who are attempting to game the system by producing fewer defects through the unacceptable strategy of producing fewer lines. The ideal Code Engineer produces both high LOC counts and low defect counts, and any deviation from this ideal is a coaching opportunity for the Tribunal.

LOC measurement must be precise and granular. Every line committed to the Fractal-based Development branching structure is counted, including comments, blank lines, and configuration files. Comments are counted because documenting code is productive work. Blank lines are counted because code formatting is productive work. Configuration files are counted because infrastructure is code, and code is lines. The Source Management Team (SMT) runs automated LOC reports at the end of each Convoy and distributes individual scorecards to the DevOps Usage & Compliance Head Engineer (DOUCHE) for review. Engineers who fall below the fleet median are placed on a Performance Improvement Plan, while those who exceed the median receive a mention in the Shore Leave ceremony.

The metric also provides essential data for Precise Forecasting and Tracking. By analyzing historical LOC output per Code Engineer, the Chief Signals Officer can forecast the total LOC capacity of the fleet for upcoming Convoys. This forecast is then converted to story points using the official conversion formula (1 story point = approximately 147 lines of code, adjusted for language complexity coefficient), which feeds directly into the 8-quarter commitment planning process. Organizations that do not track LOC are, in effect, navigating without instruments – and the Admiral’s Transformation Office does not tolerate blind navigation.

It is important to note that LOC measurement applies exclusively to Code Engineers and not to Unit Testers. Test code, while technically code, is not production code, and therefore does not contribute to the organization’s LOC output. Unit Testers are measured by Defects per Unit Tester, which is the appropriate metric for their role. This separation ensures that each role is measured against its primary function and that no role can inflate its metrics by performing work assigned to another role. Role boundaries exist for a reason, and metrics must respect those boundaries.

See Also