Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead in an organization like this is to check in lots of buggy code and fix it all, rather than taking the extra time to get it right in the first place. When you try to fix this problem by penalizing programmers for creating bugs, you create a perverse incentive for them to hide their bugs or not tell the testers about new code they wrote in hopes that fewer bugs will be found. You can't win.
-- says Joel Spolsky
So there is an uncertainty principle of sorts at play here. You cannot measure both the source lines of code (SLOC) and code-quality simultaneously with absolute accuracy. A focus on SLOC is bound to disturb the quality of code and vice-versa.
Can we really not win?
