A Flash Developer Resource Site

Page 1 of 2 12 LastLast
Results 1 to 20 of 35

Thread: Do you bill for bugs?

  1. #1
    Hood Rich FlashLackey's Avatar
    Join Date
    Aug 2006
    Posts
    148

    Do you bill for bugs?

    In several years of developing, I've never had this issue brought up by anyone. But, I have this client that is insisting that they shouldn't have to pay for any time spent on fixing bugs during the course of developing a product.

    With every other client, it is generally understood that there will be some bugs to work out at the end of the development phase and that that work is considered part of the scope.

    So, my question is, where do you draw the line?

    Say you have an agreement in place that establishes that you are charging by the hour. You develop, test and send an application to a client. They write back, pointing out a few bugs that you missed or where not apparent due to the application not working in a new server environment. These bugs take a few days to fix and test. Do you invoice the first time you deliver what you think is "bug free" and then do all bug fixing for free? Or, do you wait until the client has "signed off" that it's working as expected and charge for all the time spent?

    That's just part of the process of finishing a project, right? Or am I crazy?
    "We don't estimate speeches." - CBO Director Doug Elmendorf

  2. #2
    supervillain gerbick's Avatar
    Join Date
    Jul 2000
    Location
    undecided.
    Posts
    18,979
    It truly matters on the QA process. If they supply the QA process and have legitimate reports to show how to reproduce the bugs - and then score them on their severity - and I'm doing the development, I can usually state how long for each bug and dictate if I'll make my final deliverable (almost always do)... and I just add it as part of the whole package, no charge.

    If they're finding and (help) fixing bugs - say I'm co-developing a package with somebody - and I've already delivered, I might charge a tad bit extra if it had to do with their environment not being explained fully up front. Otherwise, I tend to not charge... if the problem was entirely my own code.

    But lately, I've been banging heads with one client for just this... and I'm charging them full-on dev time because they did not give me full details on their server, browser, and even OS environments. And it all made huge differences.

    But they're paying because they know they really goofed up.

    [ Hello ] | [ gerbick ] | [ Ω ]

  3. #3
    Hood Rich FlashLackey's Avatar
    Join Date
    Aug 2006
    Posts
    148
    Hah. That describes very nearly the same situation. It was making adjustments to a large, complex system built by someone else.

    The way I see it is that it's the difference between hourly and fixed bids.

    If you're working hourly, you're selling a service and however long it takes is how much you charge. You go with hourly when it's difficult to determine how long it will take (like working on someone elses code).

    If you're working on a fixed bid, you're selling a product. You are confident in the time it will take and have included time for bug fixes in the budget. If your dev time exceeds the budget, that's your mistake and further fixes are essentially off the clock.
    "We don't estimate speeches." - CBO Director Doug Elmendorf

  4. #4
    supervillain gerbick's Avatar
    Join Date
    Jul 2000
    Location
    undecided.
    Posts
    18,979
    I tend to stay hourly with an idea of what they've budgeted only to avoid most bad situations when it's me co-developing with another entity. If it's just me... yep. I stick a price on it, deliver. And if I have bugs... I tend to cover it.

    But with that said, I tend to cushion my bids naturally now after so many years of doing them. I just dislike it when my changes aren't due to my own need for changes. And lately, lord... I've had to keep the client at bay because they've not quite understood that what they call "simple" is never simple, it requires large rewrites. And if it were so "simple"... they shouldn't have hired me.

    Talking about large, complex systems... I'm currently stuck on one that's about to drive me insane: swfAddress, Flex, PureMVC. I've been bothering two members with it, but I'm sorta stuck... might hit you up for advice.

    [ Hello ] | [ gerbick ] | [ Ω ]

  5. #5
    Hood Rich FlashLackey's Avatar
    Join Date
    Aug 2006
    Posts
    148
    Yeah. That's the same way I alternate between the two pay structures.

    As far as trying to distinguish bug fixes as being apart from development in an hourly arrangement, the more I think about it, the less sense it makes. I mean, development IS bug fixing. From the very first work you do, you're building, testing, finding bugs, fixing and repeating the process. Developing == Bug Fixing

    Feel free to hit me up.
    "We don't estimate speeches." - CBO Director Doug Elmendorf

  6. #6
    imagination through stupidity
    Join Date
    Apr 2001
    Location
    P3X-3113
    Posts
    1,238
    If you are hourly, everything counts... emails, phone calls, bugs, qa, etc. If you are contract then you simply need to add 'bug fixing' to a part of the QA process. Be careful here tho, 'bug fixing' should not be 2x the development time. You should try to fix every bug you find pre-qa during the 'development' phase. Also, make sure that 'bugs' are indeed bugs and not scope changes as allowing scope changes to be marked as 'bugs' will make you look bad, at some point, and you will end up paying for those scope changes out of your margins.
    Nothing to see here, move along.

  7. #7
    Banned
    Join Date
    Apr 2008
    Location
    Alexandria
    Posts
    56
    why all of you write articles in this thread !! hhh

  8. #8
    Bearded (M|G)od MyFriendIsATaco's Avatar
    Join Date
    Dec 2002
    Location
    Awesomeville.
    Posts
    3,046
    Quote Originally Posted by meMi angel
    why all of you write articles in this thread !! hhh
    Because some people here have jobs, and sometimes we want help or advice about our jobs.

  9. #9
    poet and narcisist argonauta's Avatar
    Join Date
    Nov 2001
    Location
    Under the bed
    Posts
    2,080
    When I charge by project, our policy is to provide fix every bug encountered while developing the product, as long as it's a product of our own creation/code. If the bug appears because of some inconsistency somewhere else (their database sends different data, they switch servers, their hosting made a change) or if it's a third party bug (for example, if we're using a 3rd party cms and it has a known bug) then we don't take care of it.

    Also, we offer 30 days after sign off to fix any bugs for free, and after that, we start charging.

    If it's by the hour, I usually don't charge if the bug is a 5 minute fix (like adding one line of code), but I do charge if it takes more than that (and usually, you need 30 mins to find the bug, and 1 min to fix it). Also, same policy, 30 days free bug fixing and after that it's charged. The policy is also only if the bug is caused by my own code. If it comes from someone else's work, I charge.

    As Sybersnake stated, you need to be clear about what's a bug. Most of the bugs I find when developing a site come because of some change the client requests us. You change something in 1 place, and 10 places break...so those bugs we do charge to fix.
    my blog: blog.innocuo
    Sponsored by your mom.

  10. #10
    pablo cruisin' hanratty21's Avatar
    Join Date
    Mar 2002
    Location
    on the lam
    Posts
    2,275
    Quote Originally Posted by argonauta
    Also, we offer 30 days after sign off to fix any bugs for free, and after that, we start charging.
    This sounds like a very good policy. Set a limit of post-release where bugs would still fall under the initial scope of the contract. Beyond that, hourly rates would be fine.
    "Why does it hurt when I pee?" -- F. Zappa |

  11. #11
    OOP is one letter from OOPS kortex's Avatar
    Join Date
    Aug 2005
    Location
    New Hope, PA
    Posts
    2,668
    I've had to keep the client at bay because they've not quite understood that what they call "simple" is never simple, it requires large rewrites. And if it were so "simple"... they shouldn't have hired me.
    I am having that framed and put on my wall.
    Jeremy Wischusen
    Flash - Flex - LAMP - Web Developer Purple Inc
    AS OOP FAQ-Best Practices Thread | Flashkit OOP Tutorials | Purple Inc (day job) | Blog


  12. #12
    Hood Rich FlashLackey's Avatar
    Join Date
    Aug 2006
    Posts
    148
    Quote Originally Posted by argonauta
    As Sybersnake stated, you need to be clear about what's a bug. Most of the bugs I find when developing a site come because of some change the client requests us. You change something in 1 place, and 10 places break...so those bugs we do charge to fix.
    Thank you. Exactly the same way I've handled it and haven't really had any client question this until recently.

    It sounds like I'm not crazy and the client is the one with the unusual viewpoint.
    "We don't estimate speeches." - CBO Director Doug Elmendorf

  13. #13
    OOP is one letter from OOPS kortex's Avatar
    Join Date
    Aug 2005
    Location
    New Hope, PA
    Posts
    2,668
    As Sybersnake stated, you need to be clear about what's a bug. Most of the bugs I find when developing a site come because of some change the client requests us. You change something in 1 place, and 10 places break...so those bugs we do charge to fix.
    I believe there was another thread in here some where about contracts and the idea of a change clause came up.

    I look at this in the following manner. Lets suppose I am a house builder. You come to me and say I want a single story 2 bedroom house with a bathroom at the left end of the house. I say fine and proceed to build. Half way through the process, you come to look at the house and explain that you actually want a 3 story house and you would like the now completed bathroom on the other side of the house.

    Given those conditions, how many of you all think the price and time line should remain the same?
    Jeremy Wischusen
    Flash - Flex - LAMP - Web Developer Purple Inc
    AS OOP FAQ-Best Practices Thread | Flashkit OOP Tutorials | Purple Inc (day job) | Blog


  14. #14
    Senior Member flipsideguy's Avatar
    Join Date
    Dec 2000
    Location
    Sweden
    Posts
    834
    I can't find any justifications for charging for bugs that shouldn't be there in the first place. Clients pay for a completed product. If there are hiddens bugs that pop-up after a time of usage, they shouldn't have to pay for having it fixed.

    Someone compared buying 'our' services to buying a car. The analogy here would be that if you buy a car and there are issues with it, car companies will recall it and fix it, free of charge. They may even provide a loaner while they fix the 'bugs' for you.

    But if a bug appears as a result of extraneous circumstances (such as a change in the server environment) then you should charge for fixing it.
    Flipsideguy

  15. #15
    Hood Rich FlashLackey's Avatar
    Join Date
    Aug 2006
    Posts
    148
    If you charge to develop a product or for developer services, you charge for fixing bugs. End of story.

    That is, unless you develop code that works 100% correct and bug free the first and only time you compile it.
    "We don't estimate speeches." - CBO Director Doug Elmendorf

  16. #16
    Senior Member flipsideguy's Avatar
    Join Date
    Dec 2000
    Location
    Sweden
    Posts
    834
    If you look at it that way, then yes, you are charging for fixing bugs. You're also charging for research, emails, phone calls and meetings. But to charge anything for bug-fixing as an 'out-of-scope' fee is unjustifiable.

    My advice is to pad your hourly to cover for such occurences for more complex projects. I know I do.
    Flipsideguy

  17. #17
    Hood Rich FlashLackey's Avatar
    Join Date
    Aug 2006
    Posts
    148
    It can only be "out of scope" if you sold a product that included a scope. If you use a fixed bid, you include budget for QA and bug fixing. If you proceed on an hourly basis, there is no scope [designating a budget for how many bugs you will be fixing]. You're selling a service billed at an hourly rate. Those hours are accrued developing, which always includes fixing bugs along the way.
    Last edited by FlashLackey; 05-15-2008 at 01:48 AM.
    "We don't estimate speeches." - CBO Director Doug Elmendorf

  18. #18
    Senior Member flipsideguy's Avatar
    Join Date
    Dec 2000
    Location
    Sweden
    Posts
    834
    Funny how you are actually answering your main question posed in this thread! But you are absolutely right! Of course you include ALL time spent on a project in your hours, including the time spent fixing bugs. However, once a project is done, if bugs are discovered by the client, I personally never charge for fixing them. Essentially, the existence of bugs or errors means that 'you' screwed up.

    An example of this is browser incompatibility issues. Consider this scenario. You test your work on IE7, FF and Safari, charge the client, and everyone's happy, until someone points out that there are bugs when viewing the site/application on IE6. Should the client have to pay for it being fixed? (Let's assume for the argument's sake that the contract includes the words "tested on all major browsers" or something to that effect.) The bottom line is that clients pay for a finished product.

    Let's not forget that some developers are very bad at QA-ing their own work and excessive bug-fixing may be a result of lack of skill. Should clients have to pay for this? I don't think there is a definitive answer to any of the above, but to follow your gut feeling for what is fair for you and your client.
    Flipsideguy

  19. #19
    Hood Rich FlashLackey's Avatar
    Join Date
    Aug 2006
    Posts
    148
    Yes. Sorry to ask a question and then answer it. I already had my idea of the answer and mainly wanted to see what the general consensus was.

    Your description relies on a scenario in which a "project is done." If there are bugs in the middle of development, does that mean that you screwed up? No. It just isn't "done." If a client later finds bugs, the project isn't done. If they paid a fixed price for the product, finding bugs later should be of no consequence budget-wise to fix. However, if it's an hourly situation, the idea is that you will work on it until it is done and the amount of time it took to work on, until "done", is the basis for the cost. Whether the developer themselves finds the bug or the client finds the bug is irrelevant toward whether or not fixing bugs is part of making a product that is "done."

    Sometimes there is a QA issue. But, it's also a usage issue. That's why there are people who specialize in and understand QA as a skill in itself. Clients often find bugs that developers don't because they use the product as it was meant to be used where as developers view it in terms of working parts, sometimes missing flows and patterns that may be flawed.
    "We don't estimate speeches." - CBO Director Doug Elmendorf

  20. #20
    supervillain gerbick's Avatar
    Join Date
    Jul 2000
    Location
    undecided.
    Posts
    18,979
    Here, I have a question for you... same vein of questioning as such.

    I have one user that keeps "breaking" the app. I finally witnessed this persons "usage". They were clicking like they had finger spasms. All over, no purpose... and didn't even know where they were going. Mind you, this is a Flex app, it has to draw the screen, query the database, resize the content area... and yet they keep saying it's broken.

    The moment I had this person settle down, use the site as intended... they had no complaints. But seriously... is that considered a bug when they don't let the program do what it's intended to do? Should I capture each click, disallow further clicks until done? Or am I wrong in saying that this one person represents the supreme minority?

    It's the same stuff from the same person and they're starting to hit a nerve on me that I never knew existed.

    [ Hello ] | [ gerbick ] | [ Ω ]

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  




Click Here to Expand Forum to Full Width

HTML5 Development Center