Implementing features vs. bug fixing

Question

I am interested in how much of your daily work time do you spend on implementing new features compared to fixing bugs.

Answer 1

I don't code any new features as long as there are some unfixed bugs in my software.

The only reason I can think of to let a bug unfixed in my software is that it's definitely to costly to fix. In this case, we may choose to change this from 'bug' to 'known limitation' or 'known bug', and we fix the feedback we give to the user accordingly, so that the user knows exactly what's going on and why it's not fixed (see my edit below)

So typically, I spend all of my time bug fixing as long as the QA is complaining about something, and all of my time coding when it's not ! :)

I do that because :

• When a software does a lot of things, but crashes randomly, the user will get a feeling that he cannot rely on the software, and there's NOTHING you can do to fix this. ever.

• When a software lacks some features, but is good at doing what it does, the user rather thinks "That may be a great software, too bad it doesn't support X and Y... I'll check the next release in 6 months".

---

Joel Spolsky has written an interesting post on that question in his 12 steps to better code.

---

Edit to answer comments : If I'm experiencing random crashes, that's definitely a bug, not a "known limitation". Once I know exactly what is going on, and only then, I can decide whether I can fix it or not.

I was rather thinking of the following situations :

• the bug is provoked by code that doesn't belong to me (typically a third party library). If implementing a workaround is very complicated, it might be OK to wait for the third party vendor to fix it. Real world example : Clickonce doesn't work in some proxy situations... I expect Microsoft to fix it, eventually.

• If the bug is that a specific feature doesn't work in all situations, and that this feature is too difficult to implement for those specific situations, I think it's ok to warn the user before he uses the feature that what is trying to do is not implemented, rather than just crashing.

Answer 2

It depends on the project, if there is a show stopper bug I focus on it but sometimes when I'm not motivated enough I just add one new cool feature so I can at least work on it instead of not doing anything.

This is for personal projects or before pre-release / research products

Answer 3

It all depends on kind of project I am working upon currently. If the project is new then we do have a phase called bug fixing after the testing phase. Most of the bugs get fixed there. (!)

If the project is maintainance project then fixing bugs is a daily routine.

Answer 4

Since I don't get paid to maintain any project, most of the time i'm working on new projects, hence adding new features all the time.

However, each feature needs to be tested and debugged thoroughly, so you can say that 30-40% of the time spent implementing a feature will go into debugging it.

Answer 5

It depends on the bug.

Is it a minor cosmetic issue such as mislaigned label or a huge knock out bug that corrupts data?

Even if it is minor or cosmetic, is it causing user headaches, like a pop-up opening up in the wrong place? Is the data corruption bug only in Firefox 2 with a full moon (and your corporate intranet is IE 6)?

Good question though...

Answer 6

Many projects have a development phase ("code thaw") where active adding of new features occurs concurrently with bug fixes, and a "code freeze" stage where feature set is frozen and 100% of the work goes towards bringing the critical bugs count to 0 (or fixing as many bugs until a fixed deadline as possible), so the answer would depend on the stage your project is in.

When I "do bugs," I also make my best effort to claim at least one feature to work on at the same time, or (when encountering a particularly buggy block of code) request a mandate to refactor the entire block. Thus I get to do some new development (and, face it, most of us prefer to write new stuff to fixing the old) while reducing the bug count.

Answer 7

There's a broad spectrum of priorities I have in my head when I'm triaging my work:

1. Bugs affecting a customer's ability to do their business or access their data. No work is done until any bugs like this are taken care of.
2. Other high priority bugs or features. These are usually "known issue" type bugs or enhancements that have become to painful to deal with anymore and now require a code change. Also, features requested by big customers or prospects generally fall into this category.
3. Everything else. This includes maintenance, nice-to-have features and just general itch-scratching-type maintenance on our code base.

As you can imagine, #3 category work doesn't get worked on all that often, which is a bit frustrating from an engineering perspective. But, our customers love us since they get an engineer working on their issues almost immediately after they call our support line and generally have a resolution within 24 hours, regardless of their size or importance.

Answer 8

I work for a group inside my company that is suppose to both create "featurettes" and respond to customer issues. I tend to spend more time on high priority customer issues (read: bugs). So I would say my time is nearly 100% spent on fixing bugs.

That said, lets read between the lines a bit. It seems that this question is a way of saying "ugg, I spend so much time on bugfixing...wish I could do more feature development". If that is the case, I think you need to look inward a bit.

As I said, I spend nearly all my time on fixing bugs for customer issues, but I have also written a ton of tools to help with that process. I have everything from specialized log analyzers to generic visualstudio solution file error checkers. Not to mention some of those sweet wndbg scripts I have written for esoteric breakpoints!

It is by doing stuff like that where I fulfill that desire to work on "something new". And in a way, it is much more rewarding than implementing some new small cog in a huge enterprise application.