Untimely feedback as a root cause of tech debt

Have you ever worked on a brand new codebase with talented engineers, only to find out a year later that it turned into the same “archaeological strata of quick fixes” as your last legacy project? I know I have, and it happened many times.

My go-to blame target for this was usually micromanagement and imposed unrealistic deadlines. And I’m sure these play a significant role in it. But a recent conversation led me to understand another cause of this – untimely feedback. Or, to be precise, feedback that was requested or given too late.

I think many of us know the story. Someone starts working on a new capability. They spin off a feature branch and keep tinkering with it for a couple of days. Then they submit a PR. Thousands of lines, large diffs, the feeling of being overwhelmed and then the despair when you find a fundamental flaw in the design. The one that is not disqualifying, but one that would require a complete rewrite to do the thing correctly.

From there, there are two options. And neither of them is good.

First, you can point that out and request changes. This is also known as “being that person”. Nobody wants to have this label. Plus it frequently results in a heated back-and-forth when the author desperately wants to avoid spending another week on a full rewrite.

The other option is to let that pass. You reluctantly approve the PR and the code lands in the trunk. You know it will cause trouble in the future and it inevitably does. The codebase got worse, the tech debt increased. But you don’t want to be that person and don’t want to have “the talk” with your manager about The Velocity.

You might think that this could have been avoided if the author asked for feedback first. But why didn’t they? Is it because they like to work this fait accompli way? Most likely not. In fact, maybe they did ask for early feedback but nobody provided it.

This also happens a lot. Someone writes a high-level description of a solution and… no one bothers. It would require taking this description and translating it yourself into something more tangible. That’s the way to spot a problem from a high-level description. It constitutes an effort, often much bigger than just glossing over a ready-to-review solution. This creates a cycle that is hard to break:

• People don’t ask for early feedback, because they don’t think they’ll receive it
• Late feedback is not given, because it’s too late
• Code with design flaws gets merged, not because of someone’s bad faith or inability to write a good one, but because two pairs of eyes are usually better than one

My takeaway from that is to ask for early feedback more often. Even if I don’t believe in receiving it, just creating a possibility of it might pay off in the future. And to try to push myself to give early feedback whenever it’s viable, even if I don’t feel like making this mental effort. As a side benefit, this would also make the development process more collaboration-based than sign-off-based, which is definitely a win.