|
It drives me nuts when programmers brag about their productivity, measured by how many lines of code they've written. You end up with something like feature 1: +12,544 / -237 lines. Done in 2 weeks. Then comes feature 2, 2 and a half months later, the stats: +5,428 / -9,845. Look at that, you had to tear down everything they wrote because they cared about amount of code over code quality. The more they brag, the more you think "oh s$%t, every line they add is a line I'm going to have to completely untangle and refactor." I think software engineering productivity can be measured, though not well by today's standards. There will probably be a decent algorithm to do it in the future that takes in to account the power of the code, how easy it is to build on top of, how robust it is, etc. |
How could that be possible? Consider the following, very typical scenerio.
You write 2000 lines of code, implementing a feature. I write 2,200 lines of code, implementing a feature in a way that supports our vertical for the next 5 years (you just take my module and plug it in, instead of coding from scratch). Add in whatever time interval you want to make it more complicated - I took the same amount of time as you, less, or more.
Consider that this is a judgement call - did I or you do the right thing? We understand the risks and costs of premature design, but also understand the risk of coding exactly to today's requirements, with no insight into the future. No algorithm is going to tell you the right answer, and by the time we know (5 years from now) the measurement will be useless.
Or we each write a heuristic to the TSP. What algorithm could possible decide whose work is more "productive"? I put it in scare quotes because I don't even know how to define productivity in that regard. Yours runs faster, mine took 1/2 the time to code. Yours is 70% larger than mine, which has cache coherence implications as we continue to add to our programs. Yours is well documented (give me an algorithm to tell if code is 'well' documented), mine is sparse. I used gotos, you used exceptions to deal with errors. You wrote it in Haskell, I did it in C++. Yours will make features X,Y,and Z easily possible, mine makes A,B, and C easy. Your heuristic performs better for some graphs, mine performs better on others.
Who is more 'productive' here? It's not even a meaningful question. Bottom line is, we both tackled a hard problem, both did fine in very different ways, and both have implications on the future of the company (assume a,b,c,x,y,z are really important in the future).
It's an N-dimensional optimization problem with endless unknowns, and no knowledge or agreement on how to measure many of the axis', let alone their relative importance to each other.