What % of programming time do you spend debugging? What do you think are acceptable percentages for certain programming mediums?
+2
A:
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.
Anthony
2010-02-24 12:42:29
+1
A:
Hi there.
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.
Cheers. Jas.
Jason Evans
2010-02-24 12:44:36
+1
A:
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.
dbemerlin
2010-02-24 12:59:39
Have you looked at stackoverflow careers yet? ;)
Yukiko
2010-02-24 13:03:39
Ouch. As they say, "If you can't change your company, change your company"
Anthony
2010-02-24 13:07:51
What are you complaining about? They let you use git! They could have forced you to use VSS because git is too complex for new programmers. (Or worse, they could say source control takes too much time)
Benjol
2010-02-24 13:52:19
They chose git because it's free and decentralized... after we lost our complete SVN repository to a hard disk crash (no, there were no backups... well, actually the server SVN was on _was_ the backup server). Source Control Software is actually a new invention in this company, a year ago adding a .old, .bak or even .defunct to the filename was the proper way to store old versions (i found a file with 15 versions having 14 different extension styles)
dbemerlin
2010-02-24 16:12:19