Documenting and planning for technical debt

When I met with my boss to discuss this, he said I should include refactoring in all my estimates. He said it's not a problem he wants to think about. Instead, I should handle it.

This isn't a problem that management in general wants to think about. They aren't the engineers, you are. Just make this an unspoken part of all of your estimates, and you'll find that the technical debt decreases.

It will never be perfect though. Technical debt, like credit card debt, is an investment in getting customers faster and gaining market share over your competitors faster. Like credit, if managed properly, it can make you quite successful.

If you can bend the user-specific requirements into something that will be useful for everyone, great. If the client is willing to pay the ongoing support costs for the feature, also great. But if you're a small team and you find yourself struggling to support all your features, there's nothing for it but to make some hard decisions about the features you need the least, and then invest some time rooting them out of your codebase.

SaaS puts you in a good position to gather usage statistics. You should look at tooling up your features if you haven't already so that you can keep a track of who's using what. Our experience is that the most idiomatic customers are usually also the most dysfunctional; that guy who stamped his feet and held his breath until you gave him an export-to-MS-Access button probably hasn't used it in over a year. Some features are kept alive even though only one customer is using them, because that customer is loud and threatens to take his business elsewhere every time something's not to his satisfaction. Discontinuing the feature might cost you a customer now, but the time consumed in supporting that feature may cost you dozens of customers over the years. It is a measure of the quality of your management team, whether or not they are willing to make that sort of decision.

When you do discontinue a feature, make sure to announce the decision to your customers (or at least those affected) well in advance, anywhere between six months and three years is reasonable. In fact if you find yourself agreeing to build user-specific features you might try to get your sales staff to build an expiry date in from the start. Call it the "support lifetime", and make it clear that the longer they want it the more money it will cost. Try to provide workarounds for your clients so they're not left floundering when a feature goes, for example a script that converts your exported XML files into MS-access format, or a bit of advice about choosing a better RDBMS.

Something that's worked for us as a preventative measure is to get a report from our sales team sent to our development team and management on a monthly basis. This report covers feedback from clients -- what features are most popular, what features are most requested, what proposed features are generating the most buzz. This is interesting if you're a developer but the real benefit is to the sales team, who are now thinking a bit more about each feature in the context of the bigger picture, instead of sending in an endless stream of feature requests and prioritizing based on which client was the loudest. The effect has been to make our sales staff more hard-nosed when it comes to new feature requests in a negotiation because they are more conscious of where each feature might fit into the overall value proposition of our product.

Having modular code with lots of automated tests will help you when you're hacking features into your product and hacking them back out again, but ultimately this isn't a programming question but a management one. Writing code to make a sale is a fool's game.