What are "custom software companies"?
By "custom software companies" I mean companies that make their money primarily from building custom, one off, bits of software. Example are agencies or middle-ware companies, or contractors/consultants like Redify.
What's the opposite of "custom software companies"?
The opposite of the above business model are companies that focus on long term products, whether they be deployable desktop/mobile apps, or SaaS software.
A sure fire way to build up technical debt:
I work for a company that attempts to focus on a suite of SaaS products. However, due to certain constraints we sometimes end up bending to the will of certain clients and we end building bits of custom software that can only be used for that client.
This is a sure fire way to incur technical debt. Now we have a bit of software to maintain that adds nothing to our core product.
If custom work is a sure fire way to build technical debt, how do agencies handle it?
So that got me thinking. Companies who don't have a core product as the center of their business model, well they're always doing custom software work. How do they cope with the notion of technical debt? How does it not drive them into technical bankruptcy?
Best Answer
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.