What Slows Development Teams
This article was originally published as a guest post for GitPrime in 2017, during the height of the Agile movement and the rise of DevOps practices. At the time, many teams were struggling with the transition from waterfall to iterative development, and developer productivity tools were primarily focused on basic metrics like commit frequency and lines of code.
Since then, the industry has evolved significantly with the emergence of DORA metrics, platform engineering, and more sophisticated approaches to measuring developer experience. However, the core challenges identified here around communication gaps between managers and developers, context switching, and misaligned incentives remain relevant today.
GitPrime was a developer analytics platform that provided insights into software development teams' productivity and processes. The company was later acquired by Pluralsight and integrated into their Flow product offering before being discontinued. This article represents thinking from the earlier era of developer productivity tooling, when the focus was primarily on code-based metrics rather than today's more holistic developer experience approaches.
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. – Douglas Hofstadter
Developers and managers both want scope and delivery time to align, but despite working toward a common goal, they rarely do. The gap is often so large that deadlines are missed, products become irrelevant, and teams face burnout.
Three major schools of thought explain why Hofstadter's Law persists in software development.
Three Theories of Software Delays
Software is Art
This perspective treats software development as an inherently unpredictable creative process. Since we lack centuries of established practices, we're prone to underestimating challenges and struggling to predict timelines accurately. While some claims in this school are debatable, they correctly identify that our industry struggles with measuring work, which is fundamental to measuring success.
Software vs. Entropy
This theory focuses on complexity accumulation. More moving parts make software harder to grow, maintain, understand, onboard new developers to, and ship quickly. As systems evolve, technical debt and interdependencies create friction that compounds over time.
Productivity Declines
This approach attributes slowdowns to talent, process, and environment factors. Great developers with mismatched processes, inadequate developers for specific needs, or environments that prevent focused work on mentally challenging tasks all contribute to declining throughput.
Research: Perspectives on Team Velocity
To understand these dynamics better, we surveyed 50 professional programmers and managers about their daily experiences. While the sample size was small, it revealed telling patterns about how different roles perceive development challenges.
We asked participants about:
- Software release frequency
- Their role (manager, developer, or both)
- How often specific issues slow them down
- What improves or hinders their work
Key Findings
Perception Gaps: Developers and managers experience the same problems differently. When we ranked issues by perceived severity, clear patterns emerged:
- All groups identified interruption and lack of focus as major problems
- Monthly+ shipping teams saw changing product requirements as their biggest challenge, with fewer technical debt issues
- Daily shipping teams had minimal design change problems but frequent technical challenges
- Weekly shipping teams struggled across all categories
Role-Based Biases: Developer-managers perceived all issues as more frequent than peers filling only one role. Managers focused on business-side bottlenecks, while developers emphasized technical constraints.
The Communication Divide
This reveals a fundamental disconnect. Developers constantly request time to refactor or rewrite systems, which could indicate either:
- Communication breakdowns about technology and product trade-offs
- Biased memory toward familiar technical challenges
Driving vs. Restraining Forces
What Helps Teams Move Faster:
- Agile methodologies (overwhelmingly supported across all roles)
- New frameworks and design patterns (developer favorites)
- Process automation, especially UI testing and build improvements
- Clear communication and stable priorities
What Holds Teams Back:
- Managers: Changing priorities, communication failures, constant meetings
- Developer-Managers: Slow automated processes, poor culture, firefighting
- Developers: Context switching, unclear processes, overloaded sprints, technical debt
The Theory of Constraints in Software
These perception gaps reflect a deeper organizational challenge. The Theory of Constraints describes two approaches to improving throughput:
Cost Accounting: Maximize individual step efficiency, keeping everyone at full capacity Throughput Accounting: Optimize total system output, allowing individual steps to operate below capacity
Cost accounting feels intuitive but creates competition between teams rather than collaboration. This mindset has caused manufacturing plants to fail, and it's equally problematic in software development.
Human Bias in Problem Identification
Our research reveals a predictable pattern: managers blame business-side issues while developers blame technical problems. Both groups attribute challenges to what they're most exposed to.
This isn't malicious. It's human nature. Without objective data, correctly identifying problems requires perfect memory, unbiased reasoning, accurate interpretation, immunity to social influence, and complete objectivity about one's own performance.
Loss Aversion compounds these biases. We feel stronger pain from losses than equivalent gains. In software terms, cutting quality control feels like gaining speed, while upfront design work feels like losing development time. NASA research shows how this creates exponentially expensive defects later in the process.
The Data Imperative
Individual perspectives are too narrow to identify true bottlenecks. We need broader, objective measurement to understand what's actually happening.
Consider our finding that daily-shipping developers complained about build processes. Are these safeguards slowing total business throughput, or preventing production bugs that are orders of magnitude more expensive? Without data, we're just guessing.
Meaningful metrics should answer questions like:
- Did our process changes improve outcomes?
- Are we over-polishing features at the cost of shipping?
- How do all-hands meetings affect productivity?
- Which engineers created the biggest impact?
- How much effort went toward technical debt?
Moving Forward
Software engineering is notoriously difficult to measure, and easy metrics are often vanity metrics or unfair comparisons. But difficulty doesn't justify giving up on measurement entirely.
As Peter Drucker observed, "If you can't measure it, you can't improve it." Without data, we're stuck with guesses, opinions, and office politics.
The solution isn't eliminating human judgment, but complementing it with objective measurement that cuts through bias and subjectivity. Only then can we identify true constraints and make improvements that actually matter for total team throughput.
Meaningful data transforms subjective debates into objective problem-solving, helping teams align around what actually drives results rather than what feels important to individual roles.