3 ms·

Measuring Software Reuse and Deleting Code (2014)

17 points by luu 11y ago

thomasfl 11y ago
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/ http://fagblogg.mesan.no/how-bad-is-smelly-code/
- karlmdavis 11y ago
  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!
  - thesz 11y ago
    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.
    - hibbelig 11y ago
      The outlier had nonlinear dependence. It was the file that proved the point. Why do you want to remove it from consideration?
      - thesz 11y ago
        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.
kabdib 11y ago
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.
- jacques_chester 11y ago
  The problem isn't metrics per se. It's tying them to reward and punishment.

17 points by luu 11y ago

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/ http://fagblogg.mesan.no/how-bad-is-smelly-code/

karlmdavis 11y ago
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!
- thesz 11y ago
  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.
  - hibbelig 11y ago
    The outlier had nonlinear dependence. It was the file that proved the point. Why do you want to remove it from consideration?
    - thesz 11y ago
      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.

kabdib 11y ago

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.

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