There’s a quiet dread creeping through engineering teams today—a shared sense that software quality is slipping. It’s not just one company or one team saying this. Threads across Reddit’s engineering communities echo the same sentiment: systems feel fragile, reliability is fading, and developers constantly feel like they’re one deploy away from disaster.
This isn’t paranoia. When high-profile outages, silent failures, and endless regressions become normal, the instinct that “something is off” is usually right. The real challenge is proving it. How do you measure software quality in a way that is meaningful, accurate, and resistant to being gamed? And, more importantly, how do you use those measurements to actually reverse the decline?
Veteran engineers agree: there is no universal quality score!
Attempts to compress quality into a single number inevitably break down. Instead, effective measurement requires a portfolio of signals—quantitative data, qualitative insights, system behavior, team health, and business impact.
1. Looking at the Delivery Pipeline: The True Operational Health Check
To start confirming your hunch about declining quality, you must look at the data governing your team’s delivery performance and system stability. These metrics are objective, rooted in operational efficiency, and provide a clear picture of how easily and safely your team can ship code.
The DORA Metrics (And Why They Matter)
The DevOps Research and Assessment (DORA) metrics are the gold standard for measuring Elite vs. Low-performing teams. If these metrics are trending negatively, your quality is declining, even if your feature count is high. Used by top DevOps teams and highlighted in Google’s research-backed Accelerate report, these metrics offer a clear window into how safely and efficiently your team ships software.
| DORA Metric | What a Drop in Quality Looks Like |
| Change Failure Rate (CFR) | A higher percentage of deployments resulting in immediate hotfixes, rollbacks, or service interruptions. |
| Lead Time for Changes | The time it takes for a commit to reach production is increasing. This indicates mounting friction, complex deployment pipelines, and heavy technical debt. |
| Deployment Frequency | The rate of deploying code to production is decreasing. Teams are too afraid to deploy often, suggesting a lack of confidence in testing and system stability. |
| Mean Time To Restore (MTTR) | The average time it takes to restore service after a production failure is increasing. This signals poor monitoring, poor documentation, and a lack of system resilience. |
A companion to MTTR is Mean Time To Detect (MTTD). If your MTTD is spiking, it means your alerting and monitoring tools are failing, and your customers are often the first to find your bugs—a clear sign of dropping quality.
2. Inside the Codebase: Complexity, Debt, and the Friction No Dashboard Shows
While DORA metrics focus on external flow, you also need to measure the internal state of your codebase. This is where you quantify the creeping rise of technical debt, which one engineer aptly described as the “amount of duct tape needed” to keep the system running.
Bug Density
This is the most straightforward health check. You track the total number of bugs opened per release, per team, or per thousand lines of code.
- Metric: Average Bug Density (Bugs / Unit of Code or Bugs / Time Period).
- Warning Sign: If this number is increasing while your feature velocity remains flat, you are sacrificing quality for perceived speed.
Cyclomatic & Cognitive Complexity
These metrics attempt to quantify how difficult a section of code is to read, understand, and test.
- Cyclomatic Complexity measures the number of linearly independent paths through a program’s source code. High scores mean difficult testing and high bug potential.
- Cognitive Complexity (often measured by static analysis tools) measures how difficult the code is for a human to understand, often penalizing complex control flow structures and nesting.
Tools like SonarQube, Code Climate, and DeepSource specialize in identifying these hotspots. When complexity grows unchecked, testing becomes harder, onboarding slows, and regressions multiply. Even small changes start carrying disproportionate risk, and quality declines in a way that’s difficult for leadership to see but painfully obvious to developers.
Technical debt is often dismissed as a theoretical problem, but its symptoms—fragile tests, mysterious deployment failures, and code that no one wants to touch—are unmistakable markers of declining quality.
Tracking an increase in either of these metrics across your codebase is a direct measurement of dropping maintainability and rising developer friction—the silent killer of long-term quality.
3. The Human Signals: Culture, Fatigue, and the Cost of Bad Systems
Metrics alone never tell the full story. Quality also erodes in the places dashboards can’t measure: developer experience, on-call culture, and the team’s day-to-day ability to get work done.
Developer Friction and On-Call Fatigue
Listen to your engineers. They are the early warning system.
- Developer Friction: Is it easy for a new hire to push a small change to production without assistance? If the answer is no, tribal knowledge is replacing documentation and automated processes, which is a symptom of technical debt and dropping quality.
- On-Call Fatigue: A rapid increase in PagerDuty alerts, especially during off-hours, is a direct indicator of system instability. Overworked and burnt-out developers make more mistakes, further accelerating the quality drop.
User Feedback and Requirements Compliance
Sometimes the simplest metric is the most revealing: User Surveys.
- Periodically survey your end-users (or internal stakeholders) about specific areas of your product: reliability, speed, ease of use. A consistent negative trend in any of these areas confirms a perceived drop in quality, regardless of what your internal dashboards say.
- Deliveries Made vs. Patches Required: While this metric can be misleading if used poorly (as the community pointed out), if you are delivering a high volume of features that immediately require post-release patches, it suggests a profound failure in the testing or validation phase—a clear quality deficit.
4. Establishing a Measurement Framework (GQM)
The key to preventing metrics from being corrupted is to anchor them to a specific goal, using a structured approach like the Goal-Question-Metric (GQM) framework.
- Goal (The “Why”): Define the objective.
- Example: Improve the reliability of the Checkout Service.
- Question (The “What”): Formulate questions that help achieve the goal.
- Example: What is the monetary cost of downtime for the Checkout Service?
- Metric (The “How”): Select metrics that answer the question.
- Example: Track Major Outages (frequency and length) and correlate them to lost revenue.
By defining your metrics around business-critical goals, you ensure that engineering effort is directed toward meaningful improvements, not just chasing arbitrary numbers.
This prevents teams from obsessing over vanity metrics and shifts focus toward outcomes tied to revenue, user satisfaction, or developer productivity. Resources like the SEI GQM Methodology and Google SRE Book offer deeper guidance on implementing this model.
Reversing the Decline: Quality Requires Will, Not Just Metrics
The knowledge and tooling to build reliable software already exist. The real turning point, as several engineers noted, is having the will and the capability to invest in quality.
The decision to reverse dropping quality is a business one. Quality is not free, but poor quality is expensive. It costs you in lost customer loyalty, increased engineering turnover, and the slow, grinding pace of development caused by accumulated technical debt.
To halt the decline, engineering leadership must shift focus from simply measuring “deliveries made” to measuring the cost of change and the reliability of the system over time. By combining the quantitative rigor of DORA and complexity metrics with the qualitative feedback of your users and developers, you gain the complete, human-sounding story you need to make the business case for quality—and finally reverse the trend.
High-performing engineering cultures don’t chase metrics. They build systems where quality becomes the natural byproduct of good processes, healthy teams, and sustainable delivery practices.
Further Reading: Programming Concepts That Finally “Click”: What Devs Wish They Knew Earlier
Discover more from TACETRA
Subscribe to get the latest posts sent to your email.
