Monday, August 23, 2010

Explaining Technical Debt to Managers

I've written about technical debt already, but this is a good take on how to explain why it's necessary to clean up code to your managers.

The big problem is that managers are (usually) one-step removed from the code work, so they don't see the messy code, the compromised design, or the bubble-sort you used to get the last release out on time.  So they don't see the roadblocks to adding new features very well.

And program/project managers are even further out of the loop on this - all they see is a UI and a list of features.  They rarely have any idea that a working program could have crappy code in it - if it works it must be perfect, right?

So anything that makes it easier to explain why working code needs to be changed is a good thing.  The best things are the metaphors that allow us to relate software refactoring to something the average manager can understand.

No comments: