in reply to
(OT) Proving Productivity?
I'm currently working on combining four classes into one - they all do very similar things and are all cut&pasted&modified versions of each other (although the genius author I inherited it from decided to do things slightly differently in each one, so one is mostly pl/sql and keeps its variables in organized hashes, another performs most of the logic server-side and has tons of class variables instead of hashes, etc., etc.) and I keep having to add identical functionality to each one as requirement change.
So anyway, I'll be cutting the original 5,300 LOC by at least half, possibly two-thirds (no more, because he liked writing 400 line uncommented functions). It should take about three solid weeks of work - that means I'll have 2,650/15 = -177 LOC/day! It's going kind of slow because I'm teasing the logic out of undocumented, buggy code. So I think LOC is a Load Of Crap (I think maybe my predecessor was paid by the line, and it shows).
The problem with Productivity with a capital 'P' is it's hugely subject to interpretation. Am I more productive if I grind out crummy code that works quickly? Would the time have been better spent doing it correctly, so that when the requirements change the code is flexible enough to handle it? That's part of the art of productivity - knowing when to grunt out a steaming LOC and when to carve a flawless diamond. The funny part is the better the requirements are to start with, the less the quality of your code matters.
