Who should pay for the bugs?

[Syndicated Puzzles]

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.

[AlienSpace]

Originally Posted by Syndicated Puzzles

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.

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.

[AlienSpace]

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.

[Contrabandit]

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.

[MarkFromBitmenStudios]

Originally Posted by Syndicated Puzzles

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.

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.