Justifications are not Project Goals
Essentially, I want to be able to demonstrate the effectiveness of the recent time that we've spent dedicated to bug fixes.
This is a project smell that I usually associate with stakeholder justification for time spent on anything other than new features. However, it is important to note that justifying time spent on a task (regardless of what that task is) is a common organizational requirement, but is not directly related to any project goals.
While good project management is about managing time, scope, and budget, justifying the time spent on squashing bugs is only indirectly about those things. Instead, a project manager should be focused on communicating project status or identifying and controlling deviations from the project plan.
Addressing code quality is useful for addressing technical debt, and may be justifiable in terms of improved velocity, fewer customer-facing bugs, or producing something that can actually ship. However, if you haven't identified a problem that this bug-squashing task solves, it isn't really justifiable.
Consider this quote from Voltaire:
The best is the enemy of the good.
or the YAGNI principle to see why bug-fixing that's unrelated to project goals or requirements might be misguided, unless it's genuinely measurable technical debt.
Is Bug-Fixing on Your Critical Path?
All projects should have a goal. That goal may be "deliver a whatzit that eats irreplaceable data." If your whatzit data-eating feature is not working correctly, then of course you need to:
- Fix the feature.
- Identify the extra time (if any) as a deviation from your plan.
- Refactor your plan to take the extra time into account.
- Do some kind of post-mortem or retrospective to prevent such critical bugs in the future.
On the other hand, if your whatzit happens to electrocute users of the system, the risk has been identified to the stakeholders and accepted as a known risk by the organization---and if you don't have the moral gumption to quit over a customer-killing "feature---then your project road map should not include solving that issue.
Technical Debt is Bad
For me, it's not enough to just say that we were able to fix more bugs, I want to be able to show a dramatic overall improvement in the software.
This is clearly not a requirement from anyone outside your team, and thus is off the critical path. If you have a customer or stakeholder asking for specific improvements to some aspect of your software, then that's a legitimate (and likely measurable) requirement.
On the other hand, seeking "dramatic overall improvement" without an external requirement is called over-engineering. Most time spent on a project should be related to:
- Meeting functional or non-functional requirements.
- Reducing technical debt in order to make it easier to deliver on requirements.
- Fixing actual defects that don't meet your requirements.
- Preventing predictable future defects (see "reducing technical debt" above).
- Following development practices that enable you to support your code in the future--see "technical debt" again, but don't over-engineer for potential problems that you can't measure or estimate right now.
Pithy Three-Sentence Summary
Fixing bugs is good. Preventing bugs is better. Over-engineering is best done as an intellectual exercise to impress your programming friends on a slow weekend.