12 Replies - 1991 Views - Last Post: 02 December 2015 - 07:58 AM

#1 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 2388
  • View blog
  • Posts: 5,012
  • Joined: 11-December 07

Itís Not a Bug. Itís a Feature!

Posted 27 November 2015 - 09:03 AM

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?

Is This A Good Question/Topic? 0
  • +

Replies To: Itís Not a Bug. Itís a Feature!

#2 xclite  Icon User is offline

  • I wrote you an code
  • member icon


Reputation: 1261
  • View blog
  • Posts: 4,059
  • Joined: 12-May 09

Re: Itís Not a Bug. Itís a Feature!

Posted 27 November 2015 - 09:47 AM

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.
Was This Post Helpful? 1
  • +
  • -

#3 jon.kiparsky  Icon User is offline

  • Beginner
  • member icon


Reputation: 10892
  • View blog
  • Posts: 18,588
  • Joined: 19-March 11

Re: Itís Not a Bug. Itís a Feature!

Posted 27 November 2015 - 10:13 AM

Is this code that you wrote initially, or is it pre-existing code that you came on to maintain?
Was This Post Helpful? 1
  • +
  • -

#4 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 2388
  • View blog
  • Posts: 5,012
  • Joined: 11-December 07

Re: Itís Not a Bug. Itís a Feature!

Posted 27 November 2015 - 12:24 PM

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.
Was This Post Helpful? 0
  • +
  • -

#5 astonecipher  Icon User is offline

  • Senior Systems Engineer
  • member icon

Reputation: 2389
  • View blog
  • Posts: 9,611
  • Joined: 03-December 12

Re: Itís Not a Bug. Itís a Feature!

Posted 27 November 2015 - 12:55 PM

*
POPULAR

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.
Was This Post Helpful? 5
  • +
  • -

#6 jon.kiparsky  Icon User is offline

  • Beginner
  • member icon


Reputation: 10892
  • View blog
  • Posts: 18,588
  • Joined: 19-March 11

Re: Itís Not a Bug. Itís a Feature!

Posted 27 November 2015 - 12:58 PM

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

Was This Post Helpful? 1
  • +
  • -

#7 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 2388
  • View blog
  • Posts: 5,012
  • Joined: 11-December 07

Re: Itís Not a Bug. Itís a Feature!

Posted 27 November 2015 - 01:47 PM

Sounds like you are both in agreement with me, which is nice. :)
Was This Post Helpful? 0
  • +
  • -

#8 cprop  Icon User is offline

  • D.I.C Head

Reputation: 12
  • View blog
  • Posts: 54
  • Joined: 26-August 15

Re: Itís Not a Bug. Itís a Feature!

Posted 28 November 2015 - 11:40 PM

View Postcfoley, 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. :bigsmile:

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

Was This Post Helpful? 1
  • +
  • -

#9 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 2388
  • View blog
  • Posts: 5,012
  • Joined: 11-December 07

Re: Itís Not a Bug. Itís a Feature!

Posted 01 December 2015 - 09:54 AM

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!
Was This Post Helpful? 0
  • +
  • -

#10 astonecipher  Icon User is offline

  • Senior Systems Engineer
  • member icon

Reputation: 2389
  • View blog
  • Posts: 9,611
  • Joined: 03-December 12

Re: Itís Not a Bug. Itís a Feature!

Posted 01 December 2015 - 09:16 PM

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.
Was This Post Helpful? 2
  • +
  • -

#11 jon.kiparsky  Icon User is offline

  • Beginner
  • member icon


Reputation: 10892
  • View blog
  • Posts: 18,588
  • Joined: 19-March 11

Re: Itís Not a Bug. Itís a Feature!

Posted 01 December 2015 - 11:03 PM

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.
Was This Post Helpful? 2
  • +
  • -

#12 xclite  Icon User is offline

  • I wrote you an code
  • member icon


Reputation: 1261
  • View blog
  • Posts: 4,059
  • Joined: 12-May 09

Re: Itís Not a Bug. Itís a Feature!

Posted 02 December 2015 - 06:19 AM

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!
Was This Post Helpful? 1
  • +
  • -

#13 cfoley  Icon User is offline

  • Cabbage
  • member icon

Reputation: 2388
  • View blog
  • Posts: 5,012
  • Joined: 11-December 07

Re: Itís Not a Bug. Itís a Feature!

Posted 02 December 2015 - 07:58 AM

View Postcprop, 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.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1