How do "custom software companies" deal with technical debt?

Question

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?

Answer 1

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.

Answer 2

When I am faced with custom development requests I filter them through the cool filter which splits requests into 3 piles:

1. awesome things which will be useful for everyone and are relatively easy to implement
2. awesome things which will be useful for everyone and are hard to implement
3. stupid one-of things which are only needed for this one client which doesn't really need them anyways

• Category 1 gets implemented in the current dev cycle.
• Category 2 gets implemented in the next dev cycle.
• Category 3 gets a quote of 1 man month of dev time after which most clients realize that their request is not worth it.

Honestly, this never failed and I don't think we ended up implementing any of the category 3 features. And of course none of the customers walked (sales wouldn't have let me pull this off otherwise :)

(this experience was at an ISV company)

Answer 3

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.

Your problem isn't that you're creating code that's used for only one client. The problem is that you're incorporating code that's used only for one client into a product that you're selling to many other clients who don't need that functionality.

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?

They deliver the product. And then they move on. When you're developing a product under contract, everything you do on that project is for that one client. Any technical debt that may have accrued during development becomes the client's problem after the contract ends, and the developer moves on to another project for another client.

That doesn't mean that it's okay to do a crappy job, of course. Your number one goal is to make your client want to keep working with you, and doing quality work is the way to get there. It also doesn't mean that technical debt isn't a problem for contract developers. Even if you consistently write clean code yourself, chances are that you'll be hired at some point to work on a project that has already accrued a pile of debt. That can be good (the client wants to pay you to clean up the mess) or not (the client has no idea how bad the code is and doesn't understand why "just" adding a few more features is going to take so long).

Answer 4

I disagree with the premise that custom work is guaranteed to generate technical debt. Avoiding technical debt doesn't mean avoiding certain kinds of functionality -- it means avoiding needless rigidity, dependency issues, and things that make a code base difficult (i.e. expensive) to change. Custom functionality doesn't imply any of this -- it just implies a narrow base for the functionality. So, they key is to factor as much common, reusable logic as possible out of the implementation as possible, leaving the custom, one-off stuff as its own standalone module that can be deployed for the requesting customer.

For instance, let's say that you had a deliverable that was an internal web application that your customers would install on an intranet. One day, a customer comes along and offers to drive a dump truck full of money up to your company if you'll make a version for them that has a "rich client" desktop application instead of a browser interface. Well, if your system is well architected and your dependencies well managed, this is just a matter of reusing the domain, data access, and service components while creating a new presentation component. Technical debt is not a consideration, even though you have only one customer that wants to return to 1999 and have a desktop application for this.

Answer 5

This is a somewhat complex question to answer because like many things it really depends on the circumstances of the project, the level of control the contracted company has, whether the custom software has been managed by the contracted company for it's entire life cycle, the amount of "interference" by other people with access to the code base, the attitude of all of the people involved, complexity of the project and methodologies used... I really could go on.

All systems have a degree of technical debt. In some cases this may not be particularly noticeable due to diligent efforts on the part of developers working towards always maintaining a clean code base, however no system is perfect and a major redesign can make a seemingly innocent yet long standing issue become apparent. So how do contracted companies handle this?

In many cases they don't. Often software will be written by one firm, then modified by another, and it's not unusual to see the code base get really messed up as each company under contract works to a tight deadline and won't justify the time to keep the code clean (and sometimes barely tested) if it means they might risk missing a deadline.

In other cases, you find companies that not only manage their contracted project well, but also somehow find the time to leave the existing code base in a better state than they found it. They do this often with careful planning, identifying sources of technical debt - usually those which will impact new work the most - and they devise strategies to provide test cases and modifications that contribute to managing the technical debt and factor all of this into their project schedule.

Does being a custom software guarantee technical debt as opposed to writing a central product? The short answer is no, however it is likely that technical debt will accrue if it isn't actively dealt with. This is the same as with any other software project. If you control the project entirely throughout its life cycle, then you have a better opportunity to deal with technical debt. If not, then you will need to deal with technical debt that may have accrued from the code that the previous company left behind.

On the other hand, if your question were to ask if writing software regardless of your business model is a guarantee of technical debt. The answer would be Absolutely. The real question is how any company handles technical debt. Let it accrue and deal with it at a scheduled time, or manage a clean code base in an ongoing manner in order to pay off against technical debt as soon as possible? That answer comes down to a company's individual priorities, and whether the technical debt incurred is financially relevant.

Answer 6

Custom software is not a guarantee of technical debt, but serving two masters is.

A custom software company will build a piece of software exactly fitted to the task at hand, deliver it, and maintain it if necessary. Truly custom software often doesn't need new features added very often.

The problem described in this question is when product companies build custom features into an otherwise generic product. If the product were wholly custom, it would only move when requirements at the one customer changed. If the product were wholly generic, it would move only when new features are added to make it more appealing. But when you have a custom feature in an otherwise generic product, you have two chunks of code, in close contact, that move at different speeds. Like tectonic plates that cause earthquakes, the interface between these code chunks is a "hot spot", ripe for problems.

Answer 7

You need to have a clean distinction between your core code and customer specific code, and defined interfaces between them. That makes it quite easy to deactivate the latter, and quite difficult for the latter to break the former.

On way is to have empty subroutines/methods in the standard that can be modified with user specific code. If you've heard talk of SAP userexits, it's basically that.