InsideQC Forums

How do you keep motivated when working on bugfixes?

After focusing for so long on fixing bugs, I get really demotivated. Fixing engine bugs doesn't really add anything to the game. When I fix bugs, I feel like I'm saying "look, this doesn't suck" rather than "look, this is awesome" - maybe because the things I've fixed were already supposed to be awesome, despite not working well. So, I feel like a grumpy man criticizing things instead of actually bringing some awesomeness to the table. This is specially true when fixing bugs that almost no one were concerned about.

What's your experience with this?

When I have a crippling bug, it stops me in my tracks. I can not move forward until i get that bug out! Then I'll stop any future feature development until i have tested for a week making sure that bug doesn't happen.
Then I'll move forward. If you dont like bugs, try to keep your new features sequential. Dont start multiple changes or you'll be fighting multiple bugs.

tbh, most of my bugfixing time is spent on rewriting the code instead.
the logic being that if you've a lot of hard to find bugs in some module then that's because the module is basically junk in the first place. hence rewriting it to completely avoid needing to fix the bug (and hopefully consolidating features to avoid special cases and to facilitate future extensions).
plus I tend to sit on bugs until their cause becomes a little more obvious, slightly easier to track them down then. depends if they're fatal bugs or not though.

regarding r00k's comment, typically I code out a few big/unsafe changes then leave them to settle down a bit while I work on other unrelated/minor/safer stuff before actually committing. while I should probably use multiple svn checkouts instead, the unsafe changes at least get a little testing before getting committed. I should probably point out that correct use of git can isolate each change quite nicely and still 'corrupt' the master branch infrequently after things have been modified... but I'm lazy and don't use git, it just seems like more effort.

Bugs bother me, so I'm motivated by my dislike of having them around. I do have a few bugs that keep lingering around, though, because they take so much work to fix properly.

Sadly the most confounding bugs usually turn out to be the silly random error of typos or mental lapses: problems that can't be solved by retracing logic. Rewriting seems redundant but might ultimately be the least time consuming path. More like recut-repaste-readapt in my case. I feel motivated to fix bugs, annoying but temporary obstacles in a process of 'continuous partial improvement' .

The point of this thread was a philosophical issue, not a technical one. The point is, if you release two derivative engines, one with nothing but many bugfixes, and one with nothing but many new features, most people will prefer the latter. So, if there's (hypothetically) no way to do both, why fix the bugs?

Maybe the opposite is true when the derivative sticks tight to the original game... people pick fixes over features. I was just thinking of FitzQuake and DirectQ in another thread. These are popular 'fixes' engines. Plenty of folks just want the same old stuff to suck less.

This thread managed to evade me while it was active, but I'm jumping on it now. As a precursor, I am not a programmer and do not claim to be one. But I do have almost six years experience in professional games QA (coming up on 70 titles). In all of the projects I've been on, rewriting seems to be the most effective method from a QA perspective. Fixes achieved by rewriting regress on a much smaller scale (typically: never) and create fewer bugs in other systems. Typically when they do create new bugs in other systems, said systems were put together hastily or are generally antiquated.

That being said, Fixes Over Features for me. Knock out all the big fish, then take care of the minor ones. Show me a new feature when it isn't going to be impacted by a bug from an old one which distracts me as a user. As a tester, show it to me when I'm not going to wonder "Is this behavior from new code itself, or just an old bug that has evaded our attention?"

And speaking from a project perspective, bug fixes are great for morale. QA loves to close out bugs as Fixed and verified, and everyone enjoys seeing a project "start feeling 'better'". If a game I'm working on has a fairly common but not dominant crash, but also some inventory issues, misaligned textures, incorrect art assets, and rendering issues, the crash isn't what is undermining my experience. With the crash fixed you are still looking at a bizarre and difficult to handle game.

Basic Functionality Fixes > Quality of Experience Fixes > Performance and Stability Improvements > Features > Minor Issues.

When I have a bug, I give up and kill the project and watch 0 people submit patches until I fix it 17 months later. Stay classy, open source.

leileilol wrote:When I have a bug, I give up and kill the project and watch 0 people submit patches until I fix it 17 months later. Stay classy, open source.

Haha, isn't that the truth?

Open source: A collaborative effort, where one guy does all the work, and everybody else watches.

Might feel that way but i did make a shitload of patches to other peoples work cant be everywhere at once though hehe.

Most people prefer the BSD license nowadays it seems :roll: I dont mind people using my work, not even if commercial as long as they give credit to the small guy who did the job.