You’ve just shipped a feature. The team rejoices, and management congratulates the team for making the deadline.
Sure, the team cut corners, but product is out, move on to next product.
But then defect reports start coming in.
In a typical org, after they get past customer (support|success), the reports will land with the product (manager|owner) who begins the rework of prioritizing the bug reports against new work.
Development will likely contribute to the discussion and sometimes take on fixing the defects, all rework, which is waste.
Do you measure this?
In basic accounting, you track assets and liabilities. In software accounting, we typically only track the assets.
You shipped code, great. You can’t build a business if you can’t ship. But are you also tracking the rework caused by the decisions made in the process of shipping that code?
Shortcuts taken today will cost money later if you want to keep working on that code base. For example, Ruby on Rails’s ActiveRecord can provide amazing shortcuts for getting things running quickly, but the standard doctrine on how to use it will inevitably lead to monster classes that everyone is afraid to change.
Bugs don’t just spring into being. Software, once committed, remains exactly as it is. There are no crappy code gremlins or demented elves that tinker with the code in your repositories. Every defect can be traced back to some moment or moments of human hands on keyboards. And this isn’t to say your developers are bad. There are systemic reasons why decisions are made.
It’s not just bugs either. How much time do your developers spend trying to figure out how to accomplish work items vs. accomplishing them? That friction exists because of past decisions.
If you just accept bugs and slowdowns as a reality that can’t be dealt with, you won’t track the cost of rework and slowdowns. If you don’t track their cost, you won’t perceive a problem. If you don’t perceive a problem, you can’t improve the situation. If you can’t improve the situation, you are consigned to forever fighting fires.
It doesn’t have to be that way.
(Major thank you to Scott Bellware for exposing me to this concept.)
