Ask HN: Do you spend more time coding or debugging?
21–30 of 77 posts
Re: Ask HN: Do you spend more time coding or debugging?
#22Analysis Programming Debugging Overhead ------------ -------- ----------- --------- -------- My Own Stuff 30% 60% 10% 0% Others' Code 50% 10% 30% 10% Enterprise 10% 10% 10% 70%
I get your point but my guess is the lack of analysis is only exacerbating the problem on the Enterprise end.
Re: Ask HN: Do you spend more time coding or debugging?
#23 60% debugging
15% stack overflow
25% email archives
15% commit logs
10% navigating code, spelunking
12% jira
5% writing tests to confirm config/state/feature availability
3% codingRe: Ask HN: Do you spend more time coding or debugging?
#24Re: Ask HN: Do you spend more time coding or debugging?
#25Analysis Programming Debugging Overhead ------------ -------- ----------- --------- -------- My Own Stuff 30% 60% 10% 0% Others' Code 50% 10% 30% 10% Enterprise 10% 10% 10% 70%
I get your point but my guess is the lack of analysis is only exacerbating the problem on the Enterprise end.
The overhead consists of endless meetings that never reach consensus, but arguably this could be filed under analysis
Re: Ask HN: Do you spend more time coding or debugging?
#26 """
No parts of the schedule are so thoroughly affected by sequential constraints as component debugging and system test. Furthermore, the time required depends on the number and subtlety of the errors encountered. Theoretically this number should be zero. Because of optimism, we usually expect the number of bugs to be smaller than it turns out to be. Therefore testing is usually the most mis-scheduled part of programming. For some years I have been successfully using the following rule of thumb for scheduling a software task: 1/3 planning
1/6 coding
1/4 component test and early system test
1/4 system test, all components in hand.
This differs from conventional scheduling
in several important ways:
1. The fraction devoted to planning is larger than normal. Even so, it is barely enough to produce a detailed and solid specification, and not enough to include research or exploration of totally new techniques.2. The half of the schedule devoted to debugging of completed code is much larger than normal.
3. The part that is easy to estimate, i.e., coding, is given only one-sixth of the schedule.
"""Re: Ask HN: Do you spend more time coding or debugging?
#27Re: Ask HN: Do you spend more time coding or debugging?
#28Earlier quoted context omitted.
I get your point but my guess is the lack of analysis is only exacerbating the problem on the Enterprise end.
That's where you schedule a meeting to talk about scheduling a meeting to talk about Where We Went Wrong With Analysis.
Re: Ask HN: Do you spend more time coding or debugging?
#29From The Mythical Man-Month by Fred Brooks: """ No parts of the schedule are so thoroughly affected by sequential constraints as component debugging and system test. Furthermore, the time required depends on the number and subtlety of the errors encountered. Theoretically this number should be zero. Because of optimism, we usually expect the number of bugs to be smaller than it turns out to be. Therefore testing is u…
"The data on the percentage of time spent in error removal has varied over the years, but the usual figures are 20-20-20-40. That is, 20 percent for requirements, 20 percent for design, 20 percent for coding (intuition suggests to most programmers that here is where the time is spent, but intuition is very wrong), and 40 percent for error removal."