[cfoley]

In my freelance work, I do not charge for bug fixes. If a tradesman makes a mistake when working on my house, I expect them to fix it free of charge. As such, I extend the same courtesy to my clients: If I make a mistake while developing software, I will fix it free of charge.

I recently got an interesting bug report. The latest version of the software does not work for a particular range of values. This kind of input was never specified in the requirements. It was never tested for and was never talked about, yet it worked several versions back. It turns out that it was just what the code did for that range of input back then. Since then, refactorings and features have changed things (it was a lot of versions back!) and the specific behaviour for this strange range of values has changed.

I know what I’m going to do this time around. I’m going to fix it free of charge but I the general case is interesting. What would you do in my situation if a bug report came in reporting something that had never been discussed but worked “correctly” in an older version of the software?

[xclite]

Without knowing more details about the range of values (I understand you may not be able to provide them), it's hard to say. I'd err on the side of taking fault for not having stricter input validation in the first version, or for not clarifying undefined behavior.

[jon.kiparsky]

Is this code that you wrote initially, or is it pre-existing code that you came on to maintain?

[cfoley]

It's code that I wrote initially but since I'm asking about the general case, you could tell me how your opinion would change if it was not.

Quote

Without knowing more details about the range of values (I understand you may not be able to provide them), it's hard to say.

Negative values for a physical quantity. In this case the negative makes no sense.

[astonecipher]

I agree with, if I did it, it's on me. However, if I am coming into someone else's code, I would charge, because I was not the original person to miss the "feature."

I would think a quantity field would naturally not allow negative integers, though.

[jon.kiparsky]

Since you wrote the original code, I'd say the onus had been on old you to determine what behavior the client wanted for those weird values, so now you're kind of stuck with it. If it had been pre-existing code, the onus would have been on you to determine what the previous behavior had been, and to check whether this was behavior the client cared about. ("Gosh, it looks like when someone enters a negative value for weight, they actually get billed for a negative dollar amount. Are you sure that's what you want?")
In the case where you wrote the original code, it seems clear to me that it's yours to fix. In the case where you came on as a maintainer, if you came across the problem before making changes, then I would think it would be your responsibility to confirm with the client how the behavior should work. (and hopefully to price the work based on this discussion) On the other hand, if you went ahead and changed existing behavior that was not in scope, then the client has a reasonable claim to have you restore the original behavior without charge.

This post has been edited by jon.kiparsky: 27 November 2015 - 01:04 PM
Reason for edit:: reconsidered my position

[cfoley]

Sounds like you are both in agreement with me, which is nice.

[cprop]

cfoley, on 27 November 2015 - 04:03 PM, said:

In my freelance work, I do not charge for bug fixes. If a tradesman makes a mistake when working on my house, I expect them to fix it free of charge. As such, I extend the same courtesy to my clients: If I make a mistake while developing software, I will fix it free of charge.

I recently got an interesting bug report. The latest version of the software does not work for a particular range of values. This kind of input was never specified in the requirements. It was never tested for and was never talked about, yet it worked several versions back. It turns out that it was just what the code did for that range of input back then. Since then, refactorings and features have changed things (it was a lot of versions back!) and the specific behaviour for this strange range of values has changed.

I know what I’m going to do this time around. I’m going to fix it free of charge but I the general case is interesting. What would you do in my situation if a bug report came in reporting something that had never been discussed but worked “correctly” in an older version of the software?

You honestly dug your own grave here. Your guarantee may sound great but it's not feasible in the real world. Bugs are not black and white and you're bound to get into disputes (look at your current situation). You are more likely to damage your reputation and clients by getting into disputes (they are going to feel cheated, you will feel cheated or you will both feel cheated). There are better ways to be professional and give clients the same kind of guarantee.

A better freelance approach is simple. Once you finish a contract/project, you should extend an optional retainer fee/option (say one day/month to fix any bugs or add minor features etc). This is one day of paid work per-month you set aside of the client. The client can choose to use the day or skip the day but either way they pay one day a month. This gives you guaranteed money every month per-client on retainer and makes clients more confident in that if something goes wrong they don't have to find a new contractor or debate with an old one etc. Plus, the best kind of money is reoccurring money.

No software is ever 'finished'. There are always bugs, small features, adjustments etc. That's a much better way to handle it than doing work for free.

There's a good talk that touches on this method a bit, along with other advice, it's pretty good. Check it out here.

This post has been edited by cprop: 28 November 2015 - 11:49 PM

[cfoley]

Thanks for the advice and link to the video. I was away for a few days so haven't had a chance to watch it yet.

Quote

Your guarantee may sound great but it's not feasible in the real world.

Is this a commonly-held view? The purpose was to force me to code better quality software and so nobody can object to me fixing bugs first, enabling me to work with a codebase that is clean as possible. Maybe bug-fixes is the wrong word. "Mistakes" could be a better description. A while back, I found a better way of practising TDD and since then mistakes in my code have been negligible.

I certainly don't market myself as doing free bug fixes. That wouldn't send the right message!

[astonecipher]

I disagree about it being feasible. I have held to it, the difference is scope creep and an actual bug. If I coded something and it is not meeting spec it is immoral to charge someone for something they already paid for. You are hired to paint a house red and paint it blue. Should the owner pay you to paint the house [red] again? If however, you were hired to paint the door and now they want the window sill painted as well, it is outside of the original scope.

[jon.kiparsky]

If you limit "bug" to mean "out of line with the agreed-upon requirements", and you're careful to do a good job with requirements gathering, then it's not only feasible but ethically mandatory to fix bugs. At that point, it's on you, as the developer, to minimize bugs. On the other hand, if you're not good at getting the requirements down first, then you probably shouldn't be writing software at all, since you're probably not going to do the right thing except occasionally by accident.

Quote

No software is ever 'finished'. There are always bugs, small features, adjustments etc. That's a much better way to handle it than doing work for free.

There's a big difference, in my mind, between "small features, adjustments, etc" and bugs. A bug is an incorrect behavior in some existing feature, while an additional feature is a correct behavior that hasn't been implemented yet.

[xclite]

I agree - in most cases it's possible to determine whether an "issue" is a feature or a bug. In the cases where it isn't, bill em!

[cfoley]

cprop, on 29 November 2015 - 06:40 AM, said:

There's a good talk that touches on this method a bit, along with other advice, it's pretty good. Check it out here.

I watched the talk and thought it was excellent.

However, the specific examples he gave for the retainer were changing requirements and "new security holes in Rails" which I'll generalise to external changes that affect the product (or changing requirements). He didn't mention bug fixing as part of the retainer and I think it's a big jump to assume that's what he meant.