6

You made add-ons to an app which was coded by someone else. The code does not have unit tests. Then some bugs appear cause a new code collided with existing code somewhere.

Obviously, the client will tell you "the code worked before you made add-ons, will I be charged while you fix it" as they don't know anything about regression and QA.

How do you charge regression costs if you are the only coder involved in the project? You give a discount, fix it for free or some 3rd option?

Obviously fixing it for free will not make you profit and thou you are responsible for bugs, the lack of unit tests made you not being able to predict them. Then again, if you look from client's perspective, you made a bug, and why should he pay for something you messed up.

Peter MV
  • 14,379
  • 1
  • 34
  • 67

2 Answers2

3

I try to charge enough that I can do this work for free. But some customers don't like this arrangement so sometimes I have to make other arrangements. YMMV. The question really comes down to who gets to assume risk. There should be a financial premium on assuming risk to help even things out a bit.

Here's the basic issue:

  1. The customer doesn't want to get stuck with an unknown bill for a project.

  2. You don't want to get stuck with a whole bunch of work that brings your per hourly earnings down below what you can live on.

Resolving this conflict requires adding on a basic third piece:

  • Whoever assumes the risk should get, on average, a modest financial reward for assuming that risk.

What I typically do is offer a rate that includes, free of charge, bugfixes afterwards for a year. That rate is double (!) my desired hourly rate. In most cases, I spend no time on after-market fixes. In a few cases I spend a lot of time. I try to plan so that I spend about 2/3 of my time as billable under this arrangement. This:

  1. Protects my interests and ensures I am making money.

  2. Protects my customers, ensuring they don't get stuck with large after-market bills.

For some customers though, they don't like this arrangement, and it breaks down for very large projects, so I also offer another rate in those cases (not advertised and sometimes as low as 50% my initial offer rate) with the explicit terms that the work comes with no warranty.and that I will bill for everything. On average I make a little less on these projects, but I also bear none of the testing and bugfix risk.

TL;DR: I try to throw in these free of charge by billing at a rate that allows me to make more doing this. For large projects, or certain customers, I may however shift the risk to the customer and offer a large discount. I believe that this approach best meets the interests of all involved.

Chris Travers
  • 4,836
  • 2
  • 18
  • 31
  • I read this 3 times and I still don't understand :). Can you sum up the part which refers to regression bugs? – Peter MV Feb 26 '14 at 09:41
  • For most customers I charge enough that I can throw in bug fixes for free and give the customer the benefit of the doubt. On some larger projects or for customers who want it, I charge less for my development work but charge for regression fixes. In both cases I charge for testing. But we all know testing isn't perfect. – Chris Travers Feb 26 '14 at 13:21
  • The other rule is that whoever assumes the risk of losing on a complex case where lots of bugs come up after the fact gets a slightly better deal on average. So I try to price things so that I make more money when I throw in free bugfixes than when I don't. – Chris Travers Feb 26 '14 at 13:22
0

I consider it part of the job. If there is the possibility that your code could cause bugs with existing functionality, Then that should be tested, fixed, and charged for before delivery.

If it looks like you have inherited a code base with some potential issues, I would let the client know before hand. Tell them that the previous developer didn't account for the changes you are now making, and how could they? (This removes you from blame, but isn't throwing the previous developer under the bus too harshly). As such, you will need time to make sure your new features integrate nicely with existing functionality and don't cause any new bugs.

GSto
  • 608
  • 3
  • 8