Effects of Defects: Grey Scope Creep
Is boosting productivity simple? Yes! Just cut out craploads of 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.
On average, a developer cuts off 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 kick ass 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 damn days! I call it “grey scope creep”.
At first, this statistics seems totally off. But can’t you remember such a kick ass 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 vein to reproduce… “Works on my machine”, sending it back to QA”, and finally, after a couple of round-trips, it’s fixed. Than regression sticks out an ugly head, and the high 16 man-hours per a 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 the kick ass developers only care about the joy of cutting code, not shipping the software, they got the boots. Don’t regret, 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 a software. We got 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 disappears 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 bring 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, I have some thoughts about it.