3

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?

Hiren Gujarati
  • 1,039
  • 14
  • 32
  • 1
    Do you mean bugs in your own code? Of course, that is part of the development cycle. If you mean, you are scheduled to do regular maintenance on other code of your company for 20% of the time, I guess that isn't excessive, although I'd expect this to be part of the negotions when you accepted the job. – Roland Bouman Jan 17 '10 at 10:34
  • You don't *have to* use that amount of time to fix bugs. But you will. Possibly more. – balpha Jan 17 '10 at 10:34
  • 6
    Wow, just started to program but already doing it in 5 languages AND on the iphone. 20% will not be enough to fix all the bugs ... – MartinStettner Jan 17 '10 at 10:51
  • 3
    How is this "not a real question"? Just because it's not well-written? I'm going out on a limb here but English might not be his native language! – Joachim Sauer Jan 17 '10 at 10:53
  • This question is deliciously ironic given poster's other question. – Joe Jan 17 '10 at 10:59
  • 10
    No 20% is not normal, it is extraordinary few. – Doc Brown Jan 17 '10 at 14:36
  • 3
    Actually, when you get better at programming, you'll actually spend *more* time debugging, because the actual code-writing part will be shorter! – Chad Okere Jan 18 '10 at 09:43

7 Answers7

17

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:

Community
  • 1
  • 1
stiank81
  • 25,418
  • 43
  • 131
  • 202
  • 1
    +1 Couldn't agree more. In fact after we started unit testing and then TDD, I would say we spend about 5% of our time on bugs. No lie. – Walter Jan 19 '10 at 13:10
  • 1
    Very nice, but I don't like the 'most programmers' and 'highly likely' talk. **Every** programmer spends time bug-fixing. You **will** introduce bugs. – abyx Mar 31 '10 at 10:17
  • @abyx: You're absolutely right! But if I said that every programmer will introduce bugs I'm sure someone would claim that they don't - even though they certainly do.. – stiank81 Apr 01 '10 at 06:42
  • 1
    and you need to cater to them? It's a safe and provably true generalization by virtue of the fact that people learn through trial and error regardless of what they say, it just takes a different form than what they envision "trial and error" to mean. – Geoff Aug 11 '10 at 15:18
12

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
Wayne Conrad
  • 103,207
  • 26
  • 155
  • 191
4

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

Paul Creasey
  • 28,321
  • 10
  • 54
  • 90
4

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.

Ruggero Turra
  • 16,929
  • 16
  • 85
  • 141
2

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.

Barry Brown
  • 20,233
  • 15
  • 69
  • 105
0

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.

Leo Jweda
  • 2,481
  • 3
  • 23
  • 34
  • @Laith, if by "fun" you mean "getting woken up at 2am by the shift supervisor because a bug has popped up in production," then yeah, it eliminates some (not all) of that enjoyable activity. There are still plenty of puzzles to solve, though. You just solve them while you're writing the code the first time instead of at 3am. Usually. – Wayne Conrad Jan 20 '10 at 21:10
  • @Wayne: Aren't you up programing at 2 AM? For shame! ;) – Leo Jweda Jan 21 '10 at 19:42
  • Shhhh. I don't want them to take away my "programmer" title just because I'm getting some shut-eye. – Wayne Conrad Jan 21 '10 at 19:59
  • @Wayne: Yeah, let's just keep this our dirty little secret. – Leo Jweda Jan 22 '10 at 07:32
0

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).

Marcel Valdez Orozco
  • 2,985
  • 1
  • 25
  • 24