What % of programming time do you spend debugging? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 12 years ago.

What % of programming time do you spend debugging? What do you think are acceptable percentages for certain progr开发者_JS百科amming mediums?

---

About 90% of my time is spent debugging or refactoring/rewriting code of my coworkers that never worked but still was commited to GIT as "working".

Might be explained by the bad morale in this (quite big) company as a result of poor management.

Managements opinion about my suggestions:

• Unit Tests: forbidden, take too much time.
• Development Environment: No spare server and working on live data is no problem, you just have to be careful.
• QA/Testing: Developers can test on their own, no need for a seperate tester.
• Object Oriented Programming: Too complex, new programmers won't be able to understand the code fast enough.
• Written Specs: Take too much time, it's easier to just tell the programmers to create what we need directly.
• Developer Training: Too expensive and programmers won't be able to work while in the training.

---

Not a lot now that I have lots of unit tests. Unless you count time spent writing tests and fixing failing tests to be debugging time, which I don't really. It's relatively rare now to have to step through code in order to see why a test is failing.

How much time you have to spend debugging depends on the codebase. If it is too high, that is likely a symptom of other problems, e.g. lack of adequate exception handling, logging, testing, repeatability etc. What counts as "Too high" is subjective.

If you do have to debug an error, think about making a failing test before you fix it, so that the error does not recur.

The worst that I have had to work on was a large and complex simulation written entirely without tests. Sometimes it failed in the middle of a run, and to reproduce a crash involved setting a breakpoint, starting the run and waiting half an hour or more. Then make a change and repeat. Don't ever get yourself into that morale-sapping and productivity-destroying situation.

---

There is so much variety when it comes to writing software that it's impossible to give you a solid answer. Complexity of the software can increase debugging time, for example, if the codebase is very large and the code itself is poorly written, then that could increase the amount of time spent debugging.

One way to reduce the debugging time is to write unit tests. I've been doing this for a while and found it helps reduce the number of bugs which are released to the customer.