Who should pay for the bugs?

Discussion in 'Public Game Developers Forum' started by Syndicated Puzzles, Jan 7, 2013.

  1. Syndicated Puzzles

    Syndicated Puzzles Well-Known Member

    We contracted a build outside of iLifeTouch. Going well except for bugs.

    Now here is a general question. At what point should the dev fix the bugs without demanding to get paid for work that was supposed to be working in the first place. We complained to the programmer but he insisted it was part of the process. This is the fourth update and I fear new bugs will appear mysteriously again.
     
  2. AlienSpace

    AlienSpace Well-Known Member

    May 28, 2010
    416
    0
    16
    Independent developer
    Bugs ARE part of the software writing process. Whether the dev has to fix them would depend on what terms you're paying them under. If you're just paying for work as you go, then more work requires more pay. I'm not really sure how else it would go with an external contractor... you cant just say you want X software which is Y percent bugfree... there's no way to quantify such a thing.

    So, they do some work and you pay some amount. If there are bugs then you have to pay more to fix them. If you're unsatisfied with the quality or pace of the work, then you might want to get a new dev.

    Also, you get what you pay for. Better and more expensive developers are more expensive for a reason.
     
  3. Rubicon

    Rubicon Well-Known Member

    Feb 22, 2011
    1,535
    1
    0
    Lead Programmer, Chief Bottlewasher
    Isle of Wight, UK
    I can't believe a developer has said that.

    When someone contracts a piece of work, it is completely expected that the work is delivered fully functional and bug free. In the real world that means the dev must fix them as they are found. The best contract from the developers perspective will put a cap on how long that process can last for (a year for example) but will not get him out of doing this completely.

    If you're hearing anything different, get in touch with a lawyer.
     
  4. AlienSpace

    AlienSpace Well-Known Member

    May 28, 2010
    416
    0
    16
    Independent developer
    There's no such thing as bug free. There's also no implied support period unless it was in the contract, which is why I said it depends on the terms for the work.

    Even if you wanted to stand by your work and provide bug fixes for some time after you deliver the code, in the real world other programmers will inherit that code. They might be stepping all over it creating new bugs, that then might get attributed to you. How'd you like to keep getting calls by your previous employer to fix bugs which arent really yours, or your code that's broken because they broke some other code that interacts with it? How'd you like to keep doing this months after you delivered your code and now have other contract work to worry about?

    When you hire a contractor you usually hire them per hour, or per day, but not per line of code or per feature. That means you pay for an hour and you get an hours worth of coding. A good dev will get more and better done, with fewer bugs, than a bad dev will. Again, that's why you pay them more. And if you're realistic in your scheduling and budgeting, then you've also planned for bugs to arise and money to pay for more dev work later.

    Work = money, and only a very inexperienced developer will think that you can deliver a system fully functional and bug free on the first try. Everything needs debugging, support, and updating later in software, especially when that code doesnt live in a black box.
     
  5. Patricia Curtis

    Patricia Curtis Active Member

    Jan 4, 2013
    43
    0
    0
    Games Development
    Nottingham UK
    Pay some

    I would pay, him 10% of the money and then offer him milestones for a bug free version and then only on a final fully working version pay him the last amount, but the last amount should be at least 30% of the project fee. Or use an escrow system.

    It is and has always been the developer (programmers) responsibility to fix bugs even 6 months to a year after the delivery date. Ask him if he purchased something from a shop and it broke in two days would he take it back?

    a small point, but i will say it none the less, a developer that lets bugs out of the door then says its part of the process is not a very good developer. I have been making games for 35 years and if i had his attitude my career would have only lasted a few months.
     
  6. Rubicon

    Rubicon Well-Known Member

    Feb 22, 2011
    1,535
    1
    0
    Lead Programmer, Chief Bottlewasher
    Isle of Wight, UK
    I'm with you Patricia.
     
  7. MHille

    MHille Well-Known Member

    There are different sort of contracts

    If the contract is for time and materials, as I assume it is. Then its perfectly reasonable for the developer to expect to be paid for bug fixes.

    Four updates for bug fixes does sound a little strange. Is the developer delivering each update as if its finished or are they just releases based on time ie. weekly?

    I take it that the requirements have been fixed for some time. Or have you been taking the opportunity of the ongoing development to make some improvements to the app?

    Matthew
     
  8. MarkFromBitmenStudios

    MarkFromBitmenStudios Well-Known Member

    Apr 4, 2011
    133
    0
    16
    IT Architecture, Development Project Manager
    Austria, Europe
    This. Everybody who thinks bug fixes after delivery are always included without extra payment no matter the contract is resorting to wishful thinking. I know for a fact that a lot of companies make a lot of money with those kind of support contracts that guarantee bug fixes. Same goes for development, if it's T&M then if it takes longer, then it costs more.

    It all depends on the contract.
     
  9. bramblett05

    bramblett05 Well-Known Member

    Aug 29, 2012
    5,682
    0
    0
    So does that mean after the contract is up he/she has a choice to continue to update their games with bug fixes if any?
     
  10. MarkFromBitmenStudios

    MarkFromBitmenStudios Well-Known Member

    Apr 4, 2011
    133
    0
    16
    IT Architecture, Development Project Manager
    Austria, Europe
    That's a different question, we were talking contract work.
     
  11. AlienSpace

    AlienSpace Well-Known Member

    May 28, 2010
    416
    0
    16
    Independent developer
    If you're in the position of hiring a programmer and want them to support their code and fix possible bugs later without charge, then you need to put that in the contract. If you're just paying them to work X hours then that's what you get... X hours worth of work.

    This is not difficult, it's just business 101. You hire for a service, put the details in the contract, and then you get that service and pay what you promised. If you dont think the other person completed their part of the contract then you can take them to court.
     
  12. Syndicated Puzzles

    Syndicated Puzzles Well-Known Member

    #12 Syndicated Puzzles, Jan 8, 2013
    Last edited: Jan 8, 2013
    Good discussion going on here. Thanks for the insight. We are really happy with the dev and the build. In was an hourly contract. The issue really is when do the bugs end and when does it stop costing us extra money.

    I guess we will put up with it for a bit longer but at one point it becomes ridiculous and the dev has to take some responsibility to fix stuff, especially if they expect more work or a recommendation.

    Some examples of what is going on

    You play five games everything works fine and in the sixth game you have these black boxes show up. Or in game 8 the app will crash. Or the game state doesn't save when you exit sometimes. Really frustrating stuff that sometimes makes no sense.
     
  13. AlienSpace

    AlienSpace Well-Known Member

    May 28, 2010
    416
    0
    16
    Independent developer
    Ok, so there are two separate issues here. The first is how happy you are with the work you got for the money. You say that you're happy, but on the other hand there's more bugs than you expected. So you need to consider this further.

    But, the second issue is the important one, which is your question "when do the bugs end". The answer is, unfortunately, never. Sorry. With any piece of complex software, there may be tons of bugs. Most are little tiny ones that might never affect anything, or be noticed, and some are bigger. But, all software has bugs. Look at any AAA game on any console. I guarantee you, it has hundreds of bugs. Some are bugs the developer never found, many are bugs that they knew about and intentionally didnt fix. That's just the way it goes. You either ship the game with bugs, or you never ship.

    In any case, the thing is that you have a piece of software and you want it to have zero bugs, and hence spend zero more money on it. This is unrealistic. You need to assume there are bugs, and you need to budget and schedule appropriately.

    I'm not saying that this is an excuse for why there are so many bugs in the code you're getting. Like I said above, you need to reconsider whether you need a different dev. But, there will always be some bugs in code. Even fixing those bugs can create new bugs. Any change at all, can create new bugs.

    So the solution is that you either need to have your own in-house programmer that can tackle bug fixing, feature change/additions, etc, or you continue to contract out when these issues arise. If the current dev is not meeting your needs, then get a new one. But the first step is to be realistic about your expectations and planning.
     
  14. AlienSpace

    AlienSpace Well-Known Member

    May 28, 2010
    416
    0
    16
    Independent developer
    I forgot to ask... can you tell us what the QA process is/was for the game (or particular features, or whatever) that this programmer delivered to you?

    I think we can give you better advice if we know more about how the game was tested before being delivered to you.
     
  15. Contrabandit

    Contrabandit Member

    Oct 3, 2012
    8
    0
    0
    Allow me to chime in. I'm not a game developer, but I am a web developer who has worked with outside contractors and sometimes been an outside contractor myself.

    First off, no good developer will knowingly ship code with bad bugs in it - we're too proud. We will squish the bugs first if we can, or notify the client of the bugs we know about if they can't squish them in time. That being said, for some bugs, it can be difficult for the developer to see them beforehand, since they will often use the code that they produce in different ways than their clients or their clients' clients would. Even just one more pair of eyes looking at what I've built has found nasty bugs in things I've written many times simply because they were looking at things differently than I could. This is especially true in the case of remote contractors, where communication with managers or in-house developers about how things should work can be limited.

    That being said, let's say I build something for you and it takes me three hours, but before I ship it I notice a bug in it, and spend another half hour fixing it. I then bill you for three and a half hours of dev time. But say I don't notice the bug, so I only work for three hours, but you notice it and send it back to me, so I spend a half hour to fix it - and still bill you for three and a half hours. Yes, it's a little different since you had to waste a bit of time notifying me of the bug, but either way, an honest dev will still bill you for about the same amount of work, whether they noticed the bug or you did.

    Now, granted, there are lots of bad contractors out there who will not be writing code to an acceptable level of quality, or, in the absolute worst case, will be introducing bugs intentionally just so they can charge you more. That's why it's very important that you check on their code yourself and make sure it's up to snuff, or that you have a highly-competent and -trusted in-house dev who can do that for you if you don't have the chops. Many times I've come onto teams and found that the other contractors were just producing absolute crap, and in all cases it was because they were hired by people who weren't skilled enough at development to know that they had hired a horrible developer. Other times, I've helped avoid that situation, since my client or boss would come to me with résumés and code samples from prospective hires and I would tell them if they were any good.

    So in short, yes, you need to pay your developers to fix bugs, but as long as you're vigilant about hiring good developers, it won't be that painful an experience.
     
  16. MarkFromBitmenStudios

    MarkFromBitmenStudios Well-Known Member

    Apr 4, 2011
    133
    0
    16
    IT Architecture, Development Project Manager
    Austria, Europe
    #16 MarkFromBitmenStudios, Jan 8, 2013
    Last edited: Jan 8, 2013
    Everything makes sense in programming. :)
    What you describe here sounds like memory issues to me, most likely severe memory leakage that sums up over many games and then becomes a problem. Those kind of bugs can be tedious to hunt down and depending on the code quality may be spread across the whole code.

    Your dev needs to do some serious Inspector work to track down and resolve these issues which can be a difficult process (Inspector is an Apple dev tool). One possibility is that the dev either does not have the skills to hunt down those kind of bugs or he does not want to admit it knowing that fixing them may take considerable time and money.

    It's all guesswork until you have somebody else look at the problem or can find out more about the code quality from your dev. You may want to request a status report about the code. For example, Apple recommends that you start the game, end up in the menu, do a snapshot, then start the game, do a snapshot, then stop it again and repeat this several times. If the memory footprint does not go back to normal (=second time you end up in the menu), then it's a clear sign of memory leakage.

    If that's the case, you can request a list of how many different game objects still hang around while you are in the menu, then an estimation of how long it takes to fix each of them.

    Asking the right questions will give you a better idea of how much time & money still needs to be spent to fix things. It also helps figure out whether the dev is able to cope with this. Some devs make quick progress by rapid prototyping but can't come up with quality code or have the skills to fix difficult problems. You may want to find out whether your dev is up to his job.
     

Share This Page