Code Ownership vs. Technical Debt

Lately I’ve been thinking about technical debt and how it’s accumulated over the course of a company. 

Thinking back upon many a software project, it’s becoming clear that a lack of decisive ownership can be a significant contributor to technical debt and frustration amongst teams.

Ownership goes far beyond just writing a design doc, or doing the odd code review. It’s holding oneself accountable for everything that happens within a codebase, from now until such time that it’s been handed off to someone else (who equally understands the role and responsibilities). 

You’re expected to work with contributors, maintain the quality bar, resist unnecessary complexity or features (the inevitable “we don’t know where else to put this feature, lets put it in this artifact”), and otherwise keep things moving forward. There’s nothing to say that ownership can be spread across a team, but everyone needs to be on the same page

If what I’ve described sounds like an open-source project, that’s by intention. I think there’s a lot that can be borrowed from successful open-source projects and applied within corporate environments. 

Over time, codebases without ownership have a tendency to be labeled as “legacy”. In the open-source world, they would likely be abandoned but in corporate america, they almost always live on. The valiant few will jump right in and try to affect change within, but more often than not, these efforts merely chip away at the surface leaving systemic issues below. To the business, this is working and (hopefully) revenue generating code. For most teams, there is little patience or motivation for maintenance when far more exciting nuts to crack are looming on the horizon. Unfortunately, there is almost always something more important than investing in your existing code.

Every so often, things get bad enough that an organization might attempt wide-scale refactoring or perhaps even small (or large)-scale rewrites. 

A cautionary tale. If you’re going to refactor your codebase, don’t just shuffle bits around. Refactor it such that you can assign ownership amongst pieces with very clear delineation