I'm interested in how companies cost in the maintenance of software and or improvement of code quality over time.

The context I would like to add, is not that of a company who have a single product where all their resource is devoted to this one area, more a company who develop many smaller projects per year for a range of customers.

My fictional example might be that of a web-design company, lets say they have 10 customers and a team of 10, there are 5 existing live sites / projects which have a small maintenance contract in place to allow for hosting costs & urgent bug fixes. There are 5 active projects, lets say with a budget of £10,000 which is earmarked for the actual development. With a prospective maintenance contract for say £1000 to cover hosting / urgent fixes.

Once these smaller, bespoke projects are delivered, how do companies sell the cost of ongoing maintenance to the customer? Most customers seem to understand that hosting incurs a cost, and that fixes / changes incur costs, but I've no idea how best to sell the concept, of say, increasing test coverage or code refactoring to improve maintainability.

I would assume many customers would assume that such quality would already be built in to their original bill, so up selling quality seems hard. However, increases in the price to accommodate the quality off the bat would likely make the company less competitive in price.

I'm curious on people's thoughts in this area or any tricks and tips which might be worth talking around.

  • 3
    I'm voting to close this question as off-topic because it is about cost in maintenance / updates – gnat Oct 17 '17 at 7:20
  • Well, its more how do people handle this situation in the context of a particular kind of organisation, less so about the costs of maintenance. So for example, do most factor this in up front? charge a large maintenance fee? assume code goes stale and out of date? – dougajmcdonald Oct 17 '17 at 7:38
  • I used to work for a software house whose primary income was selling maintenance. That is to say, once they bought our software and they wanted support beyond simple bug fixes, they had to pay a yearly rate. This also unfortunately meant whatever request the client had, however ridiculous had to be taken seriously. So ultimately it was great for business, but less so for proper program maintenance. – Neil Oct 17 '17 at 7:42
  • 1
    @Neil agree 100%. Once you start making customizations based on a small number of customers, it is similar to consulting, not maintenance. From that perspective, true maintenance is a type of insurance: the cost to maintain must not exceed the combined revenue from all clients. – Frank Hileman Oct 17 '17 at 16:56

No customer pays for "increasing test coverage or code refactorings", they pay for bug fixes and new features.

(assuming your customer is not a software vendor himself who bought some library from you.)

These things are no end in itself, they are a means to an end, which is to keep the source maintainable and evolvable. So it should be in the own interest of any professional software vendor to invest some effort into things like test coverage and refactorings for any active product, with the goal to keep the overall effort of fixing bugs or adding new features - together with the effort for refactorings - as low as possible.

Of course, whenever a software vendor sells a product, they probably want to motivate the customer for assigning a maintenance contract for as long as possible. So it is often a good idea, as long as a maintenance contract is in place, to automatically deploy new versions of a product, including bug fixes and some new features, to keep it visible to the customer that his investment into maintenance pays him back. But how the vendor achieve this goal as cost efficient as possible is up to him, that is not the customer's concern.

If your company has not any maintenance duties for a specific piece of software, and the software is not evolved any further, there is no point in doing any refactorings. If a piece of software or a module inside your program is not expected to be touched for the next years, there is no point in applying any major refactorings to this specific module.

So in short, it is always a tradeoff. Refactorings and tests are a kind of investment, and they must be balanced by the potential effort and risks one expects without them.

  • I like this answer and it's certainly correct from a 'visible to the customer' perspective, but at some point if the customer wants high quality (read maintainable, few bugs) code they must pay for it whether that's up front with higher costs, timescales with a slower delivery, or afterwards with maintenance costs. It sounds like you'd advocate up front higher cost by suggesting customers won't pay for these during maintenance, which is certainly one way to go. – dougajmcdonald Oct 17 '17 at 8:18
  • @dougajmcdonald: where did I write "up front"? Refactorings should be part of the daily work of every team member. "Investing into them" means to me "educating the team to apply refactorings every day". – Doc Brown Oct 17 '17 at 8:25
  • Yeah that's what I mean by "up front" as in, the cost of applying the code quality is incorporate in the "up front" cost the customer pays rather than as part of a maintenance or upgrade path. – dougajmcdonald Oct 17 '17 at 8:27
  • @dougajmcdonald, the best way to chase customers away is by delivering a low-quality product. If a software-selling company isn't willing to invest into quality in the first release of a product, chances are that they are equally unwilling to add quality later, because they (mistakenly) believe that customers only pay for features and not for quality. – Bart van Ingen Schenau Oct 17 '17 at 9:20
  • @BartvanIngenSchenau certainly true, but often customers accept lower quality than perhaps some of my devs want to output. When I'm talking quality I'm talking things like increasing test coverage from 60% > 70% for example, the customer won't really see that benefit directly and it's not to say that 60% coverage is low quality. I'm curious in general whether people take the approach of charging more, or delivering to a lower quality (in relative terms) and how you balance say a customer who has a very limited budget vs a dev team striving for increased quality – dougajmcdonald Oct 17 '17 at 9:37

The simple answer is that they don't.

Customers perceive quality is terms of user experience. If the users like the software then the software is good.

Furthermore, when new software is introduced, if the users don't like it, that can be blamed on the specifications rather than the implementation. eg. Users hate having to click that button twice, but we specified that it had to be that way because of business reasons.

Also, the customer will have signed off on UI and design stuff when they purchased the software, and that wont change over time.

So usually "bad software" comes down to Bugs found after the sale. These will not be seen as chargeable items by the customer and there will be various contractual clauses in place to limit how man get fixed for free.

In your example of the website company, they wont touch the code for the websites unless the customer has agreed to pay for a new feature. This is when things like unit test coverage are useful. As they prevent you breaking the other features when you add the new one.

But they are increasing your profit, not the customers. So you don't normally mention them, otherwise the customer might turn around and say "Oh ok so you can do the new feature for less money then!"

  • Really interesting points @Ewan, this in particular "Users hate having to click that button twice, but we specified that it had to be that way because of business reasons." This is something we are hoping to avoid by regular frequent user testing, we need to appease an assessment board by validating any design decisions, so the business reasons are often fighting against the user experience and we need to provide evidence either way to support a decision either way. – dougajmcdonald Oct 17 '17 at 12:04
  • sure, but presumably that's all paid for as part of developing the product or feature right? ie "we would like to make our app better, but we dont know how", "Ok, lets run some user groups and see what they say.. that will be £1000 per day" – Ewan Oct 17 '17 at 12:39
  • In that particular scenario yes, it's a cost of the feature development. But let's say it's not, how would you try to sell the additional post delivery cost of reviewing and user researching? Especially when the research may prove no change is best for the users. – dougajmcdonald Oct 17 '17 at 14:17
  • Part of the risk of developing products is that your company must absorb all "cost of reviewing and user researching". If you pass that on to the client, you are doing consulting, not product development. – Frank Hileman Oct 17 '17 at 17:02
  • I think selling a post delivery review and feature suggestion would be a fairly easy sell. After the original product has been bought and paid for, or during the requirements gathering, if your are also doing that rather than just accepting an agreed spec. But it doesn't really come under your questions heading of on going maintenance/upgrade costs – Ewan Oct 17 '17 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.