What Moving Fast Really Costs Engineering

Uncontrolled velocity, frequently represented by 'moving fast and breaking things,' generates significant unseen costs. These costs manifest as accelerated technical debt, increased production incident rates, and degraded system maintainability. This approach ultimately reduces long-term development speed and operational stability.

Why This Happens

Moving fast without engineering rigor prioritizes short-term output over system quality. Teams bypass established development practices. They skip thorough design, code reviews, and testing. This generates code with immediate functional capability but inherent design flaws or bugs. These issues accumulate as technical debt. As the codebase grows, this debt slows down future development. Each new feature requires navigating or modifying an increasingly brittle system. This also increases mean time to recovery (MTTR) for incidents. Developers spend more time firefighting, less time building. This dynamic erodes predictability and introduces systemic fragility. Reliability erosion often begins here.

How to Approach It

1. Define Minimum Quality Standards. Establish clear, non-negotiable baselines for code quality, testing, and deployment. These standards must be communicated and enforced.
2. Implement Gating Mechanisms. Integrate automated checks into the CI/CD pipeline. Requires successful tests before deployment. This prevents known defect propagation. Manual sign-offs for critical changes can also be included. Effective CI/CD configurations are crucial here.
3. Allocate Debt Repayment Budget. Dedicate a percentage of engineering time to technical debt repayment. Prioritize debt based on impact on stability or future development.
4. Promote Ownership and Accountability. Foster a culture where engineers own the quality of their code. Encourage proactive identification and resolution of system issues.
5. Monitor Key Metrics. Track metrics like defect escape rate, incident frequency, MTTR, and code churn. Use these to identify areas where quality is degrading.
6. Conduct Regular Architecture Reviews. Periodically assess system design and identify architectural pain points. Plan for necessary refactoring or redesigns. Consider refactoring vs. rewriting decisions carefully.

Practical Example

A SaaS startup launched rapidly, prioritizing new features weekly. They omitted comprehensive integration tests. Their CI/CD pipeline only ran unit tests. Within months, customers reported data inconsistencies. Engineering spent a large share of their time on unplanned incident response. A critical bug, introduced by an unverified change, corrupted user preferences. Rolling back was difficult due to rapid, undocumented schema changes. Developers spent weeks reconstructing affected user data from partial backups. The incident led to customer churn and delayed two major feature releases. The engineering team initiated mandatory peer code reviews and wrote integration tests for all new features. They also started dedicating Fridays to address the most critical technical debt items. This slowed initial feature delivery but noticeably reduced incident rates in the following quarter. Their velocity, measured by completed epics per quarter, increased after the initial slowdown because fewer resources were diverted to emergency fixes.

Common Mistakes

• Ignoring Technical Debt. Believing debt will be addressed later, and prioritizing only new features. This leads to exponential growth of unmanageable debt.
• Lack of Automated Testing. Relying solely on manual QA or no testing. This allows defects to reach production, increasing incident frequency and severity.
• Absence of Clear Definition of 'Done'. Releasing features without proper definition of completion criteria, including testing, documentation, and monitoring. This pushes incomplete work to production.
• Undervaluation of Operational Stability. Prioritizing new features over system reliability. This causes frequent outages, impacting user trust and engineering morale.
• Discouraging Code Refactoring. Seeing refactoring as wasted time. This prevents addressing foundational issues and perpetuates brittle design.

We build quality gates and debt budgets into our product engineering work from the first release.

Key Takeaways

• Uncontrolled velocity creates significant, accumulating technical debt.
• This debt directly increases production incidents and system fragility.
• Long-term development speed decreases due to increased complexity.
• Proactive quality measures prevent costly rework and incidents.
• Operational stability is a prerequisite for sustainable growth.

For more on how we work, visit Better Software.

Frequently Asked Questions

What Does Moving Fast and Breaking Things Really Cost?

It creates unseen costs in accelerated technical debt, more production incidents and weaker maintainability. Teams skip design, code review and testing, so each feature gets harder to build. We see long-term speed and operational stability fall even though early output looks high.

How Does Technical Debt Slow Future Development?

As the codebase grows, each new feature means working around a more brittle system. Mean time to recovery rises, developers spend more time firefighting than building, and predictability erodes. We treat this accumulating debt as the main reason fast teams eventually slow down.

What Quality Standards Should We Set First?

We start with clear, non-negotiable baselines for code quality, testing and deployment, enforced by automated checks in the CI/CD pipeline. Then we dedicate a share of engineering time to debt repayment, promote ownership of code quality, and hold regular architecture reviews to plan needed refactoring.

Which Metrics Show Quality Is Degrading?

We track defect escape rate, incident frequency, mean time to recovery and code churn. Together they show where quality is slipping before it becomes an outage, and they help us prioritize debt by its impact on stability or future development.

What Mistakes Make the Velocity Problem Worse?

We see five. Teams ignore technical debt, rely on manual or no testing, lack a clear definition of done, undervalue operational stability, and discourage refactoring. Each one pushes defects or incomplete work into production and perpetuates brittle design.