You check your production monitoring dashboards daily. You review your DORA metrics monthly. But when was the last time you checked the health of the codebase itself?
Here's a 10-minute checklist you can run at the start of every sprint to catch problems before they become incidents.
The Checklist
1. Knowledge Concentration (2 min)
Open your git log for the last 30 days. For your 5 most critical services, count how many unique contributors made changes.
# Replace 'src/billing' with your critical path
git log --since="30 days ago" --format='%aN' -- src/billing/ | sort -u | wc -l
Red flag: If any critical service has only 1 contributor, your bus factor is 1 for that service. One resignation away from a crisis.
Action: Schedule a pairing session this sprint.
2. PR Review Bottlenecks (2 min)
Check your average PR merge time for the last 2 weeks. Most CI/CD tools or GitHub itself can show this.
Red flag: If average merge time is >48 hours, you have a review bottleneck. This directly impacts your DORA lead time metric.
Action: Identify which PRs are waiting the longest and why.
3. Test Coverage Trends (1 min)
Don't look at absolute coverage — look at the direction. Is coverage going up or down over the last month?
Red flag: Declining coverage means new code is being shipped without tests. This increases your change failure rate.
Action: Require coverage checks in CI for new PRs.
4. Dependency Freshness (2 min)
# For Node.js
npx npm-check-updates
# For Python
pip list --outdated
Red flag: Dependencies more than 2 major versions behind, especially security-critical ones.
Action: Schedule a dependency update session. Don't let it pile up.
5. Dead Code and Unused Imports (1 min)
Run your linter's unused import/variable check. In large codebases, dead code accumulates and confuses new team members.
Red flag: Hundreds of unused imports or exports.
Action: Add a lint rule to block new unused imports in CI.
6. Cross-Team Coupling (1 min)
Look at your last 10 PRs. How many required changes in code owned by another team?
Red flag: If >30% of your PRs touch other teams' code, you have a Conway's Law problem. Your architecture and team boundaries are misaligned.
Action: Discuss with the other team whether an API boundary would be better.
7. Documentation Freshness (1 min)
Check the last modified date on your main README and architecture docs.
Red flag: >6 months since last update. The docs are probably wrong.
Action: Assign someone to review and update during this sprint.
Automate What You Can
Most of these checks can be scripted and added to a weekly Slack notification:
#!/bin/bash
echo "=== Codebase Health Report ==="
echo "Bus Factor (billing):"
git log --since="30 days ago" --format='%aN' -- src/billing/ | sort -u
echo ""
echo "Avg PR Age (open):"
gh pr list --json createdAt --jq '.[].createdAt'
echo ""
echo "Outdated Deps:"
npx npm-check-updates 2>/dev/null | tail -5
For a more comprehensive, always-on view, codebase intelligence tools can track all of these metrics automatically and alert you when things degrade.
The Point
Most codebase problems are visible weeks before they become incidents. The difference between teams that catch them early and teams that don't isn't talent — it's having a habit of looking.
10 minutes per sprint. That's all it takes.
Want automated codebase health monitoring? Glue tracks code health, bus factor, knowledge silos, and dependency risks continuously.
Top comments (0)