18

Considering how software is developed during a release cycle (implementation, testing, bug fixing, release) I was thinking that one should be able to see some pattern in the lines of code that are changed in the code base; e.g. towards the end of a project, if the code becomes more stable, one should see that fewer lines of code are modified per unit of time.

For example, one could see that during the first six months of the project, the average was 200 lines of code per day while during the last month it was 50 lines of code per day, and during the last week (just before the product DVD's were shipped), no lines of code were changed at all (code freeze). This is just an example, and different patterns could emerge according to the development process adopted by a particular team.

Anyway, are there any code metrics (any literature on them?) that use the number of modified lines of code per unit of time to measure the stability of a code base? Are they useful to get a feeling if a project is getting somewhere or if it is still far from being ready to release? Are there any tools that can extract this information from a version control system and produce statistics?

Improve this question
5
  • 1
    ndepend.com/Features.aspx#BuildComparison
    – AakashM
    Feb 8, 2013 at 9:50
  • 4
    "Secondly, the mechanism being abstract, its production is subsumed in its design. In this respect a program is like a poem: you cannot write a poem without writing it. Yet people talk about programming as if it were a production process and measure "programmer productivity" in terms of "number of lines of code produced". In so doing they book that number on the wrong side of the ledger: we should always refer to "the number of lines of code spent"." - The fruits of misunderstanding, Edsger W. Dijkstra.
    – yannis
    Feb 8, 2013 at 9:51
  • 3
    @Yannis Rizos: I am by no means suggesting to measure productivity or code complexity by LOC because I know that this is not a good measure. On the other hand, if 300 lines of code were changed two days before shipping, I as a manager would have a big "RED ALERT" lamp in my mind (unless this was planned and is the result of a very careful evaluation of the risks). In general, I would assume that code that has been used (and tested) without being changed for a long time is "more stable" than code in which 100 lines are changed every day.
    – Giorgio
    Feb 8, 2013 at 9:56
  • 2
    @Giorgio Argh, I was interrupted (middle of the workday here) while I was posting another comment (hit the char limit in the first one). Didn't mean to imply you were talking about productivity, the Dijkstra quote just came to mind and I thought it'd be interesting. In any case, code churn metrics come quite close to what you're looking for, and there's tons of literature on them. As for tools, Atlassian's FishEye is spectacular.
    – yannis
    Feb 8, 2013 at 10:13
  • @Yannis Rizos: It is indeed a very interesting reading. As for FishEye, we use it at our work place (for reviews), so I will immediately look into the manual and see what kind of statistics we can produce.
    – Giorgio
    Feb 8, 2013 at 10:29

4 Answers 4

Reset to default
17
+150

One measure that Michael Feather's has described is, "The Active Set of Classes".

He measures the number of classes added against those "closed". The describes class closure as:

A class is closed on the date at which no further modifications happen to it from that date to the present.

He uses these measures to create charts like this: Active class chart

The smaller number the gap between the two lines the better.

You may be able to apply a similar measure to your code base. It is likely that the number of classes correlate to the number of lines of code. It may even be possible to extend this to incorporate a lines-of-code per class measure, which might change the shape of the graph if you have some big monolithic classes.

Improve this answer
0
4

As long as there is a relatively consistent mapping of features to classes, or for that matter, file system you could hook something like gource into your version control system and very quickly get a sense on where most of the development is focussed on (and thereby which parts of the code are the most unstable).

This assumes you have a relatively tidy code base. If the code base is a ball of mud, you will essentially see every little portion being worked on because of inter-dependencies. That said, maybe that in itself (the clustering while working on a feature) is good indication of the quality of the code base.

It also assumes that your business and dev team as a whole have some way of separating features in development (be it branches in version control, one feature at a time, whatever). If, for example, you're working on 3 major features on the same branch, then this method produces meaningless results, because you have a bigger problem than code stability on your hands.

Unfortunately, I don't have literature to prove my point. It is solely based on my experience of using gource on good (and not so good) code bases.

If you're using git or svn and your gource version is >= 0.39, its as simple as running gource in the project folder.

Improve this answer
5
  • gource also seems to be a great tool! (+1)
    – Giorgio
    Feb 11, 2013 at 10:30
  • 1
    I stumbled upon this answer, then spent the next six hours playing with Gource. I'm not sure if that deserves a +1 or a -1, but damn, that is one cool tool.
    – RonU
    Feb 13, 2013 at 14:56
  • @RonU : You can use gource to visualize the state of the repository in a custom time range. The point of it is that it visualizes activity on your code base over time. How easy the information is to interpret depends on a lot of factors, like I have explained in my answer above. Yes, it is an amazing tool if you want the "big picture", so I think that deserves a +1 ;)
    – Carl
    Feb 13, 2013 at 19:48
  • Yes, when I said "six hours," I didn't mean I ran one Gource sim for that time... just that I played around with lots of options, piped it to ffmpeg, possibly added an epic soundtrack, etc. It was quite the rabbit hole. :)
    – RonU
    Feb 13, 2013 at 23:07
  • Lemme guess. The soundtrack was the looped Harlem Shuffle ;)
    – Carl
    Feb 13, 2013 at 23:22
0

The use of the frequency of the modified lines as an indicator for the code stability is at least questionable.

At first, the distribution over time of the modified lines, highly depends on the software management model of the project. There are great differences in the different management models.

At second, the casualty in this assumption is not clear - is the lower count of modified lines caused by the stability of the software, or simply because the deadline expires and the developers decided to not make some changes now, but to make it after the release?

At third, most of the lines are modified when new features are introduced. But the new feature does not makes the code not stable. It depends on the developer's skill and on the quality of the design. On the other hand, even serious bugs might be fixed with very few line changed - in this case, the stability of the software is increased significantly, but the changed line count is not too big.

Improve this answer
3
  • "It depends on the developer's skill and on the quality of the design.": But you need at least some time to test the changes so that you have enough confidence that you have not introduced any bugs. Even the most skilled developers can do typing mistakes, e.g. if they are under pressure, have done too much overtime, or have had too little sleep. Also, if you apply the open / closed principle, after a while the number of changes (bug fixes) should decrease. Anyway, I have explicitly stated in my question that the outcome of such a measurement may change according to the development process.
    – Giorgio
    Feb 11, 2013 at 15:48
  • BTW, code can be unstable not because the developers are bad, but because the requirements are not clear and the project is still in a prototyping phase.
    – Giorgio
    Feb 11, 2013 at 16:03
  • @Giorgio: Of course you are right. But this is exactly what I wrote: The count of modified lines highly depends on too many factors. Some of them related to the code stability, some not. It is like to try to compute how many people have sex, measuring the electrical power, by assumption - less power - less lights - more sex. Although it is proven that the birth-rate is raising after big black outs. ;)
    – johnfound
    Feb 11, 2013 at 16:53
-1

Robustness is a term relating to the correct function of an instruction set, not the quantity, verbosity, terseness, grammatical correctness of the text used to express those instructions.

Indeed syntax is important and must be correct but anything beyond that, as it pertains to the desired function of the instructions by looking at the 'metrics' of the instructions is akin to plotting your future by reading the pattern of tea leaves at the bottom of you tea cup.

Robustness is measured by way of tests. Unit tests, smoke tests, automated regression tests; tests, tests, tests!

My answer to your question is that you are using the wrong approach in seeking an answer to one of robustness. It's a red herring that lines of code means anything more than code occupying lines. You can only know if code does what you want it to do if you test that it is doing that which you require of it.

Please revisit proper test harnesses and avoid code metric mystisism.

Best wishes.

Improve this answer
4
  • 3
    I have explicitly stated that I was not suggesting LoC as a measure of code complexity. I was suggesting the changes in code as a measure of code stability: does a piece of code have stable functional requirements and a stable, tested implementation fulfilling those requirements?
    – Giorgio
    Feb 11, 2013 at 9:07
  • I do not want to argue with you but respectfully guide you away from the folly of code metric meaninglessness. I reread you question and your examples all indicate a desire to infer a relationship between lines of code getting changed and the resulting robustness thereof. I get it that the more words you type, the more likely you are to make a typo. But I'm so against he principle in what you ask that I must come out strongly in favour of you abandoning your quest in this way. Good testing practices=good likelihood of robustness.
    – Sass
    Feb 11, 2013 at 9:15
  • "Good testing practices=good likelihood of robustness.": I totally agree. That's why I am suggesting that a piece of code that has been changed recently needs to be tested again before we can be confident that it is correct.
    – Giorgio
    Feb 11, 2013 at 9:22
  • There are several definitions of stability and one of them is what you're arguing for. It's a different semantic interpretation to the one I made. I took stable to mean, that it is "not subject to extreme changes" rather than "resistant to change"
    – Dave Hillier
    Feb 13, 2013 at 11:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.