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?
5
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:
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.
0
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.
5
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.
3
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.
4