Stop Guessing Technical Debt: LOC CSV Exports Fix Sprints

Gut-Feel Sprint Arguments vs. LOC-Backed Debt Tickets

One engineering lead walks into sprint planning and says, "The payments module feels messy, we should refactor it." The PM asks for evidence. The lead has none. The ticket gets deprioritized, and the mess grows for another quarter.

Another lead walks into the same room and drops a CSV on the table: payments/service.py grew 4,200 LOC this quarter, test files grew 180 LOC, and the file now has 11 functions over 300 lines. The PM asks how long the cleanup will take. The lead already has the number, because the LOC trend tells the story.

That second lead is who this article is for. If you run code reviews inside a polyglot codebase and you keep losing the argument for refactoring time, the gap is not persuasion. The gap is measurement. Technical debt tracking only works in agile when the debt is visible, comparable, and exportable at review time. A multi-language LOC counter paired with CSV exports is the cheapest, most defensible way to get there.

Single-Language Counters vs. Multi-Language LOC Coverage

The trap most teams fall into: running cloc on the Python service, a separate tool on the TypeScript frontend, then hand-waving the Go sidecar because "it's small." Three months later, nobody can compare debt across repos because the numbers were never normalized.

A multi-language LOC counter fixes this in one pass. It walks every repo, identifies languages by extension and shebang, and produces a single dataset where Python, TypeScript, Go, Rust, and SQL lines sit in the same schema. That comparability is the entire point. Without it, you are not tracking debt. You are collecting trivia.

Checklist: What Your LOC Counter Must Produce

• Per-file breakdown, not just per-repo totals. Debt lives in files.
• Code vs. comment vs. blank split per language. A 2,000-line file with 1,800 comments is a different problem than 2,000 lines of dense logic.
• Language tag on every row so you can filter the CSV later.
• Stable file paths relative to repo root, so diffs between runs are meaningful.
• Timestamp or commit SHA on each export, because LOC without a point-in-time reference is useless for trend analysis.

If your counter misses any of those, switch tools before you build any reporting on top of it.

Eyeballing Dashboards vs. CSV Exports Piped Into Review Checklists

A dashboard feels productive. You open it, see some bars, feel informed, close it, and forget the numbers by the time you open the first pull request. Dashboards are great for ambient awareness. They are terrible for action at review time.

CSV exports are the opposite. They are ugly, flat, and unglamorous. They are also exactly what you need to turn LOC metrics into a code-review weapon. Export the file, sort by LOC descending, and the top 20 rows are your review queue for the week.

Concrete Workflow: From Export To Review Comment

1. Run the multi-language LOC counter across all repos at the start of the sprint.
2. Export the result as CSV.
3. Open it in a spreadsheet. Filter to files with LOC > 500 AND language = python OR typescript.
4. Sort by code_lines descending.
5. Pick the top 5 files that also had commits in the last sprint (cross-reference with your git log).
6. For each, write a review checklist item: "File X is now 1,840 LOC. Before approving new logic here, confirm it belongs in this module or propose an extraction."

That is not a vibe. That is a number attached to a file attached to a decision. When the PR author sees "1,840 LOC, +320 this sprint, 0 test files modified", the conversation shifts from defensive to constructive.

A Real Calculation You Can Steal

Track a simple ratio per module: production LOC divided by test LOC. If payments/service.py is 4,200 production lines and the test file is 600 lines, the ratio is 7:1. If last sprint it was 5:1, the module is accruing debt faster than it is accruing coverage. Flag it. Log it. Bring it to the next sprint planning session as a debt ticket with the ratio as the acceptance metric: "Refactor is done when the ratio drops below 4:1."

Retro Confessions vs. Review-Stage Debt Capture

Most teams discover technical debt at the retro. Someone says, "The auth flow was painful to work on this sprint." Everyone nods. Nothing is measured. Nothing is ticketed. Two sprints later, the same complaint returns.

The alternative is to capture debt at the moment of review, when the file is already open and the numbers are fresh. When a reviewer sees a 900-line file with a 400-line function, they should not just approve with a comment. They should log a debt entry.

Debt Capture Checklist For Reviewers

• Is the file over your team's LOC threshold? (Define one. 500 is a reasonable start.)
• Did the PR add LOC without adding tests?
• Is the file's language one that tends to accumulate debt in your codebase? (Check the CSV trend.)
• Does the file appear in the top 30 rows of your last LOC export?

If two or more answers are yes, the reviewer creates a debt ticket on the spot, references the CSV row, and tags it with the sprint. This is how debt stops being folklore and starts being a backlog item with a paper trail.

"We'll Fix It Later" vs. Debt Burn-Down Tracking

"We'll fix it later" is the most expensive sentence in software. Later never comes, because later has no metric, no owner, and no trigger. Debt that is not measured grows. Debt that is measured but not tracked still grows. Debt that is measured, exported, and compared sprint over sprint is the only kind that actually gets burned down.

Burn-Down Checklist

• Baseline export: Run the LOC counter today. Save the CSV. Name it debt_baseline_YYYYMMDD.csv.
• Sprint delta: At the end of each sprint, run it again. Diff the two CSVs by file path.
• Flag growth: Any file that grew more than 200 LOC without a corresponding test-file change is a debt accrual.
• Flag shrinkage: Any file that shrank is a debt paydown. Celebrate it in the retro with the actual number.
• Trend chart: Plot total LOC per module over time. A flat line is stability. A rising line is debt. A falling line is a team that is winning.

This is the loop. Count. Export. Diff. Review. Ticket. Burn down. Repeat. No dashboards required, no expensive platforms, no vendor lock-in. A multi-language LOC counter and a CSV file are enough to run this entire process, and they are enough to win the argument in sprint planning.

The Reviewer's Job Is Not To Approve Code, It Is To Govern Growth

If you take one thing from this, let it be this: code review is not a gatekeeping ritual. It is the cheapest moment in the software lifecycle to measure and constrain technical debt. By the time debt reaches production, it is expensive. By the time it reaches a retro, it is already folklore. At review time, it is still a number in a CSV, attached to a file, attached to a person who can decide to fix it now instead of later.

Run the counter. Export the CSV. Bring the numbers into the review. Stop arguing from feelings. Start arguing from lines of code, test ratios, and sprint-over-sprint deltas. The debt will not disappear, but it will finally be visible, and visible debt is the only debt that gets paid down.