Software complexity has long been a topic of interest for engineering teams seeking to maintain productive, sustainable codebases. The problem is, both complexity and productivity have multiple definitions, which makes it difficult to prove correlation — let alone causation.
In this blog post, we explore different types of software complexity and recommend practical ways to measure both complexity and productivity in your engineering organization.
Two common measures of complexity — cyclomatic complexity and cognitive complexity — aim to quantify different aspects of how difficult code is to understand and maintain.
Cyclomatic complexity, introduced by Thomas McCabe in 1976, measures the number of linearly independent paths through code. It focuses on control flow structures like if statements, loops, and switch cases. Each branch in the code adds to the cyclomatic complexity score. A function with a single path has a complexity of 1, while multiple nested conditions can drive the score much higher.
Cognitive complexity, developed in 2016 by SonarSource, attempts to capture how difficult code is for humans to understand. While it considers control flow just like cyclomatic complexity does, it also accounts for factors like nesting depth, recursion, and breaks in the linear flow of code. The key insight is that some code structures that add cyclomatic complexity, like a simple if/else statement, don’t necessarily make code harder for developers to comprehend.
The relationship between these metrics illustrates an important point: there are multiple valid ways to think about complexity. Other metrics like Halstead complexity (1977) focus on operands and operators, while maintainability indices attempt to combine multiple measures. Each metric captures different attributes that contribute to overall complexity.
While many engineers intuitively believe that complex code hampers productivity, establishing a clear research-backed connection has proven surprisingly difficult. The challenge lies partly in the nature of software development itself — productivity is notoriously difficult to measure, and developers work on tasks of varying inherent complexity.
The most relevant research tends to focus on specific aspects of the relationship. Studies have found correlations between complexity metrics and defect rates, with more complex code generally being more bug-prone. Other research has examined how long it takes developers to comprehend code of varying complexity levels in controlled settings. However, these studies stop short of demonstrating a direct impact on overall developer productivity.
A key limitation is that most complexity metrics were developed to identify potentially problematic code, not to predict productivity impact. McCabe’s original cyclomatic complexity paper focused on identifying modules that would be difficult to test thoroughly. Similarly, cognitive complexity aims to flag code that humans will struggle to understand, but doesn’t make specific claims about productivity effects.
To definitively prove a link between complexity and productivity, researchers would need to overcome several significant challenges:
First, they would need reliable ways to measure both complexity and productivity across different contexts. While complexity metrics are well-defined, productivity measurements are far more contentious. Simple git metrics like lines of code or commits per day don’t capture the full picture of developer output.
Second, they would need to account for the many confounding variables that affect productivity. Developer experience, domain knowledge, tool quality, and countless other factors influence how quickly work gets done. Isolating the impact of code complexity alone is extremely difficult.
Third, they would need to consider that some complexity is inherent to the problem being solved, while other complexity is incidental to the implementation. A simple metric can’t distinguish between necessary and unnecessary complexity.
Some organizations have attempted to study this internally by analyzing their development data. They might look for correlations between complexity metrics and cycle time, or examine whether teams working with more complex codebases complete fewer story points. However, these analyses often struggle with small sample sizes and difficulty controlling for other variables.
The most promising approach may be to look for natural experiments — situations where similar teams work with codebases of significantly different complexity levels. Even then, establishing causation rather than mere correlation would be challenging.
Perhaps the most practical path forward is to focus less on proving a universal link between complexity and productivity, and more on understanding how complexity affects specific development activities. For instance, consider how complexity impacts:
This more focused approach might not definitively answer whether complexity reduces productivity in all cases, but it could provide actionable insights for engineering teams making decisions about code quality and technical debt.
For now, teams must largely rely on experience and judgment when evaluating whether complexity is hampering their productivity. While this may not satisfy academic standards of proof, it allows for practical decision-making informed by both metrics and context-specific knowledge.
The relationship between complexity and productivity remains an open research question worthy of further study. Until more definitive evidence emerges, teams would do well to treat complexity metrics as useful signals rather than precise predictors of productivity impact.
Complexity metrics shouldn’t be treated as strict limits. A well-structured function might reasonably exceed typical complexity thresholds if it’s handling inherently complex business logic. Complexity metrics are signals that warrant investigation, not rules that must never be broken.
For engineering teams focused on maintaining high productivity, complexity metrics are most valuable as trending indicators. Sharp increases in complexity can flag areas that may need refactoring. Tracking complexity over time helps ensure technical debt doesn’t accumulate to the point where it seriously impedes development velocity.
The most effective teams tend to take a balanced approach — they monitor complexity metrics while recognizing that some complexity is inevitable and even appropriate. Regular refactoring keeps complexity in check without enforcing arbitrary limits that might make code less clear. This pragmatic stance acknowledges that the ultimate goal is maintainable, understandable code that enables sustained productivity.
While complexity metrics can offer valuable insights, they shouldn’t be your first focus when working to improve engineering effectiveness. Start by implementing DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service. These fundamental measurements will help you identify your real bottlenecks and opportunities for improvement.
Only after you understand your DORA metrics should you consider whether complexity might be contributing to any problems you’ve identified. For example, if you see high change failure rates in certain areas of your codebase, complexity metrics might help explain why. Similarly, if lead times are consistently longer for certain types of changes, investigating complexity could reveal whether it’s making those changes more difficult than necessary.
If you do decide to track complexity, do so with clear purpose rather than measuring it simply because you can. Make complexity part of your code review conversations only when there’s evidence that it’s creating real problems. When reviewing code with high complexity scores, explore whether the complexity reflects inherent difficulty or if there are opportunities for simplification.
Consider incorporating complexity assessment into your technical debt tracking, but focus particularly on areas where you have concrete evidence that complexity is slowing down development or increasing defects. These specific instances often represent the highest-leverage opportunities for improvement.
Maintain perspective about complexity metrics within your broader engineering effectiveness efforts. These metrics are just one tool among many, and often not the most important one. Use them thoughtfully when they can provide insight into specific problems you’ve identified through more fundamental metrics, but don’t let complexity measurement become a distraction from more pressing concerns.
The relationship between complexity and productivity may be difficult to prove definitively, but targeted investigation of complexity in problematic areas can help teams make better decisions about where to focus their maintenance and refactoring efforts. Start with DORA metrics, identify your real bottlenecks, and only then consider whether complexity metrics might help you understand and address specific challenges in your codebase.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
