By Arjun Mehta
PMs usually don't interact with code directly. But you should understand what your codebase looks like.
You don't need to learn code. You just need to understand its health.
Metrics That Matter
Lines of Code: How big is the codebase?
find . -name "*.py" -type f | xargs wc -l | tail -1
< 10,000 lines: small, easy to understand 10,000 - 100,000: medium, manageable 100,000 - 1,000,000: large, complexity building
1,000,000: very large, significant complexity
Number of Files: More files = harder to navigate
Duplicate Code: How much code is duplicated?
10% duplication: high, refactor needed 5-10%: moderate < 5%: good
Test Coverage: What percentage of code is tested?
80%: good 50-80%: adequate < 50%: poor, risky
Cyclomatic Complexity: How complex is the code?
< 5: simple 5-10: moderate 10-20: high
20: very high, refactor needed
Dependency Count: How many dependencies?
100: too many, bloated 20-50: reasonable < 20: minimal
Code Age: How old is the code?
Large amount of old code = either stable (good) or abandoned (bad)
Creating a Health Dashboard
Run these metrics monthly and track changes. Plot them over time. Look for:
- Complexity increasing? Red flag.
- Coverage decreasing? Red flag.
- Duplication increasing? Red flag.
- Lines of code doubling every quarter? Red flag.
Interpreting the Numbers
Healthy codebase:
- Lines of code stable or growing slowly
- Test coverage > 80%
- Complexity: most functions < 10
- Duplication < 5%
Warning signs:
- Lines of code doubling every quarter
- Coverage dropping
- Complexity increasing
- Duplication increasing
Crisis signs:
- Lines of code 10x in one quarter
- Coverage near 0%
- Average complexity > 20
-
20% duplication
How to Use This Information
If healthy: keep the team moving. Continue current practices.
If warning signs: allocate time for refactoring. "We're seeing duplication increase. Let's spend one sprint reducing it."
If crisis: pause feature work and invest in recovery.
Communicating to Leadership
Healthy: "Our code is well-maintained. This supports fast feature development."
Warning signs: "Our test coverage is dropping. If we don't address this, velocity will slow down in 2-3 months."
Crisis: "Our codebase is in poor health. We need to pause features and invest in refactoring."
Frequently Asked Questions
Q: Which metric is most important?
Test coverage. If tests are comprehensive, other metrics matter less. Poor coverage is a red flag.
Q: How often should we measure?
Monthly. More frequently is noise. Less frequently and you miss important changes.