Measuring Software Reuse and Deleting Code (2014) | Hacker News Reader

Measuring Software Reuse and Deleting Code (2014)

weblogs.java.net

17 pointsluu7 comments

Come up with a metric and someone will try to game it

- By outright lying

- By collusion (e.g., the classic dev / QA agreement where someone makes bugs, someone finds them, and someone quickly fixes them, or by not reporting bugs through the bug system so they remain under the radar)

- Tweaking the code to meet the metric but not the spirit (adding many do-nothing layers to a system to artificially puff up code coverage percentage is a classic)

- Staging checkins (break a check-in into many sub-checkins, to appear more productive in the "check-in count" graph)

Also: Schedule padding (probably since the first construction contract, thousands of years ago), secretly trimming features or leaving them as demoware, renaming bugs as unfinished features (to be completed in "version 1.1"). The list is as old as organized work.

The problem isn't metrics per se. It's tying them to reward and punishment.

Another interesting thing to measure is how much time developers spend editiing each file. A friend of mine did excatly that by installing a logger in the IDE of all members of a team of developers. Turns out large classes are in fact evil!

We wrote a blog about it: http://fagblogg.mesan.no/how-bad-is-smelly-code/

While I intuitively agree with the conclusion there, this analysis definitely doesn't prove it...

Of course more time was spent editing files with more lines of code. In fact, if your entire application was all contained in one file, I am willing to predict that you'd (shockingly) find that all of your time was spent editing that very same file!

I agree and have to add that really interesting finding would be non-linear dependence between file LOC and editing time.

It also looks like they aren't get rid of outliers.

The outlier had nonlinear dependence. It was the file that proved the point. Why do you want to remove it from consideration?

They found that time of editing is linearly dependent on the size (finding 1). The nonlinearity of the dependence would be interesting.

There is no indication that outliers have any non-linearity.

Reply on news.ycombinator.com