| « 2.0 Yet? A Preview (Part 1) | Recommended Upgrade » |
We've all heard of ridiculous metrics used to measure job performance, often with disastrous results. When productivity is incentivized, employees figure out how to game the system.
Milo's boss, "Greg," familiar with other failed performance metrics, abandoned traditional methods and invented his own — gauging productivity by SVN Checkins per Week.
Similar to counting lines of code, this method didn't track what was checked in, just that something was checked in. Hopefully multiple times.
After a brief period of recording data, Greg noticed a disturbing trend with the staff. When he started measuring the team's performance with this metric, some of the developers that he'd previously thought were the most productive had less checkins than some those he thought were less productive. This was clearly a problem with the staff, and not with Greg's new performance metric. He called a particularly unproductive slacker into his office: Milo.
Greg: Milo, I have to be blunt. I called you in here because your productivity has been slipping.
Milo: ...it has? I haven't missed a deadline in months, and the last project I was put on couldn't have gone better!
Greg: Yes, and we appreciated your help, but can you tell me why Scott had 23 checkins yesterday and you only had four?
Milo: Well, not really. I'm not even sure what Scott's working on. In my case, I was working on the order entry system all morning and didn't check it in until the afternoon. Is that a problem?
Greg: Frankly, yes. I'm going to have to keep my eye on you and your checkins.
After the meeting, Greg announced to the team that their performance would be measured by checkins per week. Which immediately kickstarted a boom in (Greg's version of) productivity.
Both Milo and Greg were delighted to learn that with a few minor changes in the daily routine, doubling, or even tripling productivity was easy! The Unproductive Milo would have worked on a module, tested it on his local workstation, and checked changes in only after he was reasonably sure they were "done." The Productive Milo learned that this was highly unproductive. Productive Milo slowly adapted an increasingly productive technique — first checking in after each function he wrote, then after about every four lines of code he wrote, then after each line of code he wrote. His checkins (and therefore his productivity) soared.
Still, it irked Milo that he wasn't reaching his full productivity potential. He was wasting a lot of time writing code; time that should be spent checking code in. With a can-do attitude and an unquenchable thirst for productivity, he was even able to create a utility to help him be even more productive. It would, for example, convert this:
for(int i=0; i<10; i++) //Stuff
into a more-productive, more-checkinable:
const int LOOKUP_0 = 0; int i; i=LOOKUP_0; landhere1: if( !(i < 10) ) goto landhere2; //Stuff i++; goto landhere1; landhere2: if(i < 10) goto landhere1;
With his script, dubbed "PHLEGM" (Programmer's Helper for Literally Engaging in General Machination, named by one of his colleagues), he could stretch what would usually be one checkin to 20-30 commits. It's evolved like an open source project with his fellow team members adding new features.
While PHLEGM mostly served as an exercise for Milo to practice string parsing and code generation, he should technically be expecting a raise as he's increased his productivity by over 600%. And although this has been going on for the past two months, strangely his boss is none the wiser that most checkins are single-line changes, or that fixing a misspelling of "guarantee" on an order form shouldn't take more than a dozen checkins to fix. On the contrary, Milo's boss is glowing at how Milo has "turned things around."
Today, this metric is still in use. And while actual productivity and morale has declined, there has been a tremendous upswell in Greg-related jokes around the office. In one instance, one of Milo's colleagues stopped to use the ATM while they were out at lunch. He retrieved his cash, then returned to the back of the line to use the ATM again, got some more money, and got back in line again. Puzzled, Milo asked "what are you doing?"
"Dude, isn't it obvious? You get more money this way."
I wouldn't even bother with that. Subversion tends to be quite good at not getting confused over whitespace at the end of a line. I'd pick a file nobody else is every likely to use, called something like "Test23_Nov99_Y2K_1234", and write a simple program in perl to add a space to the end of each line (up to 1024 characters -- I'm not greedy, and Subversion might notice), followed by committing it. Then, I'd run it every ten seconds while I got on with my work. "Still workin' hard, Walking Boss! Still workin' hard!" 20,000% measurable increase in productivity, plus you can download a great film and watch a rather good-looking young lady wash windscreens with interesting parts of her body. "Most checkins are single-line changes." Hah! Amateurs! PS OK, technically, it's exactly the same thing. My way is less noticeable, though, and a hell of a lot more fun. |
|
A company I worked for years ago talked about rating programmers by lines of code. It never happened, which is too bad, because I had all sorts of ideas on how to boost my lines-of-code output.
1. "x=x+4"? How inefficient. Much beter to write:
2. Putting an entire statetment on a single line? Too cluttered. How about one WORD per line! Now that's productive:
3. Loops? Who needs loops. Rather than looping for, say, 20 times, better to copy and paste the code 20 times. 4. Re-using code? VERY unproductive. Better to copy and paste. 5. If the compiler can in-line a function, why not save it the trouble and do it yourself? Not only does this boost your lines of code, but it can speed up compiles! 6. Of course there's the obvious "add lots of comments". No reason to limit them to describing the code, of course. Put in comments about what you had for lunch, rambling thoughts about your co-workers, and fragments of that novel you always wanted to write. And comments praising the brilliant (or brillant) new productivity measurement system! |
| « 2.0 Yet? A Preview (Part 1) | Recommended Upgrade » |