5 ms·
Unpacking works great when it's clear what the tasks are going to be. In my experience the bulk of the work does not go into the project or tool itself, i.e. co
by webhat 13y ago
Unpacking works great when it's clear what the tasks are going to be. In my experience the bulk of the work does not go into the project or tool itself, i.e. completing the tasks, but rather into resolving issues.
I usually estimate that writing the code is anywhere from 10-20% of completing the project.
Some research shows that 1 kloc of code contains between 15 and 50 defects, and that code reviewing will pick up only 70-90%. This still leaves a lot of bugs. I sometime ago wrote up some meta research on estimating code reviewing: http://specialbrands.net/2011/10/24/code-review-in-scrum-xp-agile-mathematics/ http://specialbrands.net/2011/10/24/code-review-in-scrum-xp-...
- jacques_chester 13y ago> I usually estimate that writing the code is anywhere from 10-20% of completing the project. McConnell's book has a really excellent table of items that are left out of estimates. Nuts-and-bolts things like "API documentation", "deployment scripts", "status emails" and so on. > This still leaves a lot of bugs. Right. The classical software engineering theory is to build multiple quality gates and to study them for defects yielded. I recall that inspection stomps everything else; automatic testing came second. The problem of time-to-fix is subtly different from time-to-release, though. Software with known defects is regularly in use.