Measuring Software Reuse and Deleting Code

This a fun story rather than a deep technical discussion of some performance issue, measure or tool. My memory was jogged by a story in which Bill Atkinson reported producing -2000 lines of code on his weekly productivity report and by Kevlin Henney retweeting one of my one liners, features are the asset, code is a liability. Needless to say management wasn't impressed by having Bill report that he produced -2000 lines of code. Coders main purpose is to code and if they are producing code you should be able to count how many lines of code they've produced and consequently measure productivity.

This a fun story rather than a deep technical discussion of some performance issue, measure or tool. My memory was jogged by a story (http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt[2]) in which Bill Atkinson reported producing -2000 lines of code on his weekly productivity report and by Kevlin Henney retweeting one of my one liners, features are the asset, code is a liability. Needless to say management wasn't impressed by having Bill report that he produced -2000 lines of code. Coders main purpose is to code and if they are producing code you should be able to count how many lines of code they've produced and consequently measure productivity. The key point is that in the process of eliminating code Bill was making the software better and faster.
His story reminded me of a situation that I was in 1996. I sat down to have lunch with my supervisor and he hit me with the question, how would you measure reuse. I jokingly answered with 3 questions; what number do you need, who’s bonus depends upon it and how much of that do I get when I come up with that number. It was the look that I got from my supervisor that told me this was a serious question.

Apparently the CIO had been sold and then sold a bill of (reuse) good the company we worked for. All projects were being developed in Smalltalk using OO techniques because one of the biggest benefits would be software reuse (read cheaper to build). Indeed, the CIO’s bonus was dependent upon us hitting a certain reuse target. Time to get serious as we had to come up with a way to measure reuse. I started trolling the literature. I read article after book after article that all talked about reuse. The made wild claims of 80%, 90%, even 99.999% reuse! I swear someone would have published a 2000% reuse number if they thought no one would call them out on it.. it was that bad. I say this because out of all the publications that mentioned how much reuse they got on a project, *every single* one of them failed to mention how they managed to come up with this number. I repeat, as incredible as it sounds, not a single article talked about how to actually measure reuse!

After much searching about I finally ran into this gem (http://www.amazon.com/Object-Oriented-Software-Metrics-Mark-Lorenz/dp/01...[3]) and after reading it and a few other bits on software metrics I came to the conclusion that the reason we want reuse is to save effort. Effort in writing the code, testing the code, debugging the code, maintaining the code. The benefits come from many directions and the costs seemed to be mainly limited to the effort needed to learn how to use the code. So to measure reuse we should measure of effort saved. Of course this required that we started measuring tons of things that no one in the organization or any organization for that matter ever measured so that we could estimate the effort required to write something from scratch. Since bonus time was coming up fairly shortly it was obvious this turkey wasn’t going to fly. At this point was when Bob Moore, the cleverest guy in our group, stepped in and together we came up with a metric that unfortunately included lines of code as part of the measure.

I can’t recall the exact details of the calculation but I do recall that it yielded two numbers, some what similar to what you get from a blood pressure measurement. Of course management wanted a single number and to comply we performed the equivalent of dividing systolic by diastolic pressure to produce a management friendly single number that made absolutely no sense what so ever. My complaint was that as our group improved the frameworks that other groups were “reusing” the reuse number was going to drop. The supervisor thought that this was a ridiculous idea and so unlikely that it didn’t matter anyways. As luck would have it, a month or so laster I was asked to port a piece of our messaging system and in the process I eliminated about 60% of the code base and since that affected the LOC count portion of our “formula” and since *every* project in the company used this messaging framework everyone’s reuse number took a serious hit. By that time I believe the CIO had gotten rid of the reuse target as part of his bonus so no one cared and the project (sensibly) died shortly after that. All I can say is that we all knew it was a silly exercise going into it and in retrospect all that came out of it was this silly story about yet another ridiculous attempt to measure developer productivity.