Appropriate number of bugs

By on November 9, 2013

Our project Burnt Islands reminds me more and more about the project European Air War. We have sometimes so many bugs that a huge amount of time goes to fixing them and not actually working on new features.

So, as I look at our issue tracker (Redmine) right now we have approximately 50% bugs and about 50% features and this is after fixing a whole lot of them for the past 3 days. As we like to rest and enjoy some Thursday – Saturday drinks, one of us thought that it could be motivating if we needed to fix at least 3 bugs or features in order to earn the right to get a drink!

It became a kind of competition where the one who is not working at a day job is able to do three quick bugs due to the knowledge of the code base, while the other one needed to sit for 2 hours to get a drink!

Exhausting but also a real motivation to get things done. One of the days it took so long time to figure out the fix that it was already too late to drink! Well, it resulted that complex tasks are now divided into smaller ones so that it doesn’t take too much time to fix them. Divide and conquer is it called.

Whatever works for you this what we are doing now. But is that right? How do other indie developers do things? Do you guys also have many bugs?

3-bugs-1-drink has the disadvantage that larger and more complex bugs/features aren’t started after a while. Maybe it’s better to work 1 – 1.5 hours on the night shift before getting a drink?

One of us works as an enterprise application programmer at her day job and here is how the big guys do things:

– all major tasks are being specified and analyzed beforehand and is then divided into smaller tasks.
– developers get those small tasks and implement them in a period of 1-3 weeks (Agile / Scrum method).
– at the end of each iteration everything that was done gets tested and bugs are being fixed on the fly.
– next iteration – new tasks.

If we were using this method for our game development then the number of bugs would grow so huge after 3 weeks that I think it could take up to 1 month just to fix them. If we used those 2-3 days at the end of the iteration and no more then the game could look pretty much like “Day one Garry’s incident” game that is full of bugs and received a horrible review.

We don’t want to release a bad game, so we wonder what is the best way to do things so that you implement new features and keep the bugs down?
(oh, we can’t write bug-free code if anyone was wondering).

And what is the usual proportion of bugs vs new features in the game development industry?

Posted in: bug, code quality
Tagged: , ,


Be the first to comment.

Leave a Reply