Creative time accounting

In a recent post, I talked about the illusion of saving time by doing a poor job (quick and dirty). More often than not, a poor job comes back to haunt you with even more problems.

At the source of this problem, and many other problems, is a sort of “creative accounting” when it comes to time. Or how else to explain that there’s never enough time to do it right but always enough time to do it over? This dysfunctional mismatch happens when your performance indicators take a too narrow view:

• One metric tracks how fast engineers “ship” code

• Another metric tracks the time it takes to resolve incidents and bugs

If you don’t track the latter, you’re doing creative accounting. In reality, time saved by cutting corners must be repaid, with interest, when dealing with bugs. Even if you track both, but apply them individually to different teams (with one team responsible for new features and another team responsible for fixing bugs), you’re incentivizing the former to cut corners at the expense of the latter.

There are a few more places where creative time accounting can blind you to what’s really going on in your organization:

• Time saved by generating AI workslop → Time wasted reviewing and refining it

• Time saved by skipping comprehensive automated tests → Time wasted when adding a new features breaks an old one

• Time “wasted” via pair programming (two developers working together, live, on the same problem) → time saved waiting for (multiple rounds of) code review

The pattern should be clear by now: We want to optimize for the total time a work item flows through our system. If we only look at one station, we ignore the impact changes to that station have on the rest of the system, which often work in the opposite direction of our initial tweak.

So, account for all of the time, not just some of it, so you don’t get blind-sided by these effects.