Who is Richard Ewing?

Richard Ewing is a Product Economist and AI Capital Auditor. He is the Founder of Exogram, a verification infrastructure for AI. He audits R&D spend and surfaces hidden capital risks like technical debt, AI cost overruns, and zombie infrastructure. He has scaled B2B SaaS from $0 to $25M ARR. Published in CIO.com, Built In, Mind the Product, and HackerNoon.

What is a Product Economist?

A Product Economist treats product decisions as economic decisions. Instead of measuring velocity or story points, a Product Economist measures Return on Invested Capital (ROIC), Cost of Goods Sold efficiency, and technical debt in dollar terms. The methodology was coined by Richard Ewing.

What is the Technical Insolvency Date?

The Technical Insolvency Date (TID) is the specific quarter where maintenance costs consume 100% of available engineering capacity, reducing feature velocity to zero. Calculate yours free at richardewing.io/tools/pdi.

Exogram is verification infrastructure for AI, founded by Richard Ewing. It prevents hallucination propagation with admissibility control planes and state-hashing commit enforcement. LLMs generate language; Exogram maintains reality.

How do I calculate technical debt cost?

Use the free Product Debt Index (PDI) calculator at richardewing.io/tools/pdi to quantify hidden technical debt in dollar terms, calculate your Technical Insolvency Date, and benchmark against industry standards.

How much does AI cost per query?

AI costs range from $0.0001/query for small models to $0.10+/query for frontier models like GPT-4. Use the free AI Unit Economics Benchmark (AUEB) at richardewing.io/tools/aueb to calculate your specific AI cost structure.

Glossary/Cyclomatic Complexity

Technical Debt & Code Quality

2 min read

What is Cyclomatic Complexity?

TL;DR

Cyclomatic complexity is a quantitative measure of the number of linearly independent paths through a program's source code.

Cyclomatic complexity is a quantitative measure of the number of linearly independent paths through a program's source code. Invented by Thomas J. McCabe in 1976, it counts the number of decision points (if statements, loops, switch cases) plus one.

A function with no branches has complexity 1. Each if/else adds 1. Each loop adds 1. A function with complexity 10 has 10 independent paths that need to be tested for full coverage.

Benchmarks: 1-10 is simple and low risk. 11-20 is moderate complexity. 21-50 is high complexity and hard to test. Above 50 is untestable and should be refactored immediately.

High cyclomatic complexity is one of the strongest predictors of bugs. Research shows that modules with complexity >20 are 5x more likely to contain defects than modules with complexity <10. It's also the primary driver of long testing cycles — each independent path needs its own test case.

Why It Matters

Cyclomatic complexity is one of the most reliable leading indicators of maintenance cost and bug risk. It's measurable, actionable, and directly correlates with testing effort. Teams that enforce complexity limits (e.g., max 15 per function) consistently produce more maintainable, less buggy code.

How to Measure

1. **Per Function**: Use static analysis tools (SonarQube, ESLint, pylint) to measure complexity per function.

2. **Module Average**: Average complexity across all functions in a module.

3. **Hotspots**: Identify the top 10 most complex functions — these are your highest-risk code.

4. **Threshold**: Set a maximum (e.g., 15) and fail CI builds that exceed it.

Frequently Asked Questions