Is boosting productivity simple? Yes! Just cut code! One problem here. The gap between code complete and feature done is bigger then it appears. That was my thought as I was looking at statistics.
Reposted [and edited - Mishkin] from www.softwarefrontier.com by Dmitri Zimin(e)
On average, a developer cuts 300 lines per day, some true heroes claim more. This â€œproductivityâ€ comes with the price of 100 defects per 1000 lines of code. Finding defect and fixing it is on average 4 to 16 hours  
Do the math: Your star developer produces 500 lines a day. This creates up to 80 hours of extra work to himself, the dev team and their tester buddies. 10 days! I call it â€œgrey scope creepâ€.
At first, these statistics seems totally off. But you can surely remember such a super-star code monkey? You surely know a few. Now go over all these steps to fix a defect: cutting the build, installing it in QA, testing, finding the bug, writing a bug report, assigning it back to development, reviewing, trying in vain to reproduceâ€¦ â€œWorks on my machineâ€, sending it back to QA, and finally, after a couple of round-trips, itâ€™s fixed. Then regression sticks out its ugly head, and the high 16 man-hours per bug looks too good to be true.
So, is boosting productivity simple? Yes! Less bugs in, more bugs out! One problem here. But enough on problems, letâ€™s get positive and move on to how fight grey scope creep.
First, if these superstar developers only care about the joy of cutting code, not shipping the software, they get the boot. Donâ€™t regret it, they produce more work then they get done. It is not about developers developing and testers testing. It is developers and testers working cooperatively to ship software. We’ve got no space for local optimization.
Second, good software practices are to the rescue. Pair programming, design and code reviews, test driven development, etcâ€¦ They surely slow down the LOC/day pseudo-performance (less bugs in) and reduce the number of defects. Pair programming by itself brings 15% less bugs, with healthy 15% slow-down of LOC performance .
Third, redefine â€œdoneâ€. Fresh features are marked done, and then disappear somewhere in QA to eventually fire back at unknown time with unknown bugs. Grey scope creep. Stop it. Instead, insist on taking less but making it â€œdoneâ€ within an iteration. Done reads fully developed, thoroughly tested, debugged, fixed including regression, and accepted by product owner. If this brings development to a deadlock, itâ€™s one of the two. You may be blessed to fail faster and cheaper. After all, if you canâ€™t get â€œdoneâ€ just one feature, how would you ever be done with the entire project? Or the team overcomes the crisis and changes the working habits. The shortened feedback loop and fixing bugs as you make it leads to less time per bug fix. The grey scope doesnâ€™t creep beyond the iteration. Problems become obvious early enough to to deal with them.
Finally, until you fix the grey scope creep, your estimations could be off, up to 10 times! Measure well.
So, is boosting productivity simple? Yes! One problem here. Trying to address it may expose the stakeholders to too much truth about the state of the project. Figure out how to deal with this truth. Or wait to my next blog entry… I have some thoughts about this too.