Why do I spend 20% of my time fixing bugs? Is this normal? [closed]

Closed. This question is opinion-based. It is not currently accepting answers. 开发者_JS百科

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

I have just started to write code in C, C++, Java, ASP.NET, C#, Objective-C, I-Phone, etc.

But I don't understand why i have to spend 20% of my time for fixing bugs.

I just learned those programming languages as they are. Do most programmers face this type of problem?

---

You don't necessarily have to spend 20% of your time fixing bugs litteraly, but - yes - most programmers have to face the problem of bug fixing. Hopefully you'll be able to spend less than 20% on your time bug fixing, if you're not careful it might even take more of your time.

No matter how good a programmer you are it is highly likely that you'll introduce a few bugs at some time. If you're diciplined with unit testing you can hopefully avoid bugs best possible. I highly recommend you to look into Test Driven Development (TDD) if you want to do your best for avoiding bugs.

There are several questions about unit testing and TDD on StackOverflow if you need help getting started. Here are a few of them:

• Is unit testing worth the effort
• TDD vs Unit Testing
• How to start unit testing or TDD
• Should I use TDD?
• Getting started with TDD
• Getting started with TDD, interfaces and Mockups

---

No, most programmers have it worse than 20%.

If you want to get ahead of the game, you'll start writing tests to go along with your code. Google for:

• test first programming
• test driven design
• behavior driven design

---

Bugs will always crop up and should always be tackled as soon as possible, that way the code is fresh in your mind.

---

For example you are able to write, but in your post there are some "bugs": no space after comma, space before comma, no space after dot, "Programmers" is not a name of someone, so it's better "programmers". Now you can use 20% of your time to fix them.

---

It's kind of an odd question. If I may take the liberty to rephrase it...

Why am I spending so much time fixing my own mistakes?

Focus your energy on not making them in the first place. There are many things you can do to minimize mistakes:

• Be clear ahead of time what the inputs, outputs, and side effects of your methods are.
• Break down your problem into small, easy-to-write functions and methods.
• Write lots of tests.
• Write testable methods.
• Proofread your code before you hit that compile/run button.
• Have someone else proofread.

As you gain experience, you'll find that the easy mistakes become less frequent and the hard ones (usually resulting from poor design or unknown behaviors in libraries) start consuming more of your time.

---

Fixing bugs is a part of programming, whether you like it or not, it'll always be there.

It's been there for as long as programming has been around and it'll be there until we program no more.

It's so common you can find it in many of the the common programming jokes.

And like Wayne, most people spend a lot more than 20% of their time on debugging.

Personally, I think debugging is what makes programming fun, not because it's fun per se, but because it takes you so long to fix and once you've fixed it you get this overwhelming feeling so "WOOHOO! I did it!"

Again, I agree with Wayne on trying those techniques for programming, however, they take all the fun away from programming.

One thing I found useful when debugging is to take a break and then come back to your code after a few minutes, preferably after a short conversation with a friend or a phone call, you'll be amazed at how fast you can spot bugs, the hardest part is getting the will to stop programming and taking a break.

---

No, you DON'T have to spend 20% of your time fixing your own bugs.

Nobody mentioned anything about PSP/TSP, but reducing bug-fixing time is what PSP (Personal Software Process) is all about. Usually it enables one to reduce bug-fixing time to less than 10% right from the start, by formalizing your design documents & reviewing them according to a checklist; standardizing your code, reviewing it according to a code review checklist too; and then proceeding to compile and test.

Eventually you reduce your bug fixing time to near zero percent, as you become better at reviewing your designs and code. The basic idea is that it takes alot less time to fix a bug in the design document, or by reviewing the code; than the time it takes to find and fix a bug in unit tests, and more so than integration tests.

If you use good design reviews, code reviews and unit-testing, your bug-fixing time should be below 10% almost every time, I'm, on average, below 7% (according to my statistical data).