Trying to quantify the quality of a code base is pointless, impossible, or both.
Consider this. A perfect piece of code (from an engineering standpoint) has these characteristics:
- Free of bugs (serves intended purpose)
- Never needs to be modified
- As short as above characteristics allow
- As efficient as above characteristics allow
If you make these assumptions, hits-of-code indicates poor quality. It shows that the coder introduced bugs, failed to foresee what the code would need to do, or just didn't write it concisely or efficiently enough.
But because we'll always have to fix bugs and modify code, a more realistic set of characteristics is this:
- Easy to fix bugs (readable, well-organized)
- Easy to learn (see above)
- Easy to make changes
It's a completely different list, but hits-of-code still might indicate poor quality. It might mean that the coder is constantly refactoring, which means there will be more bugs and more learning time for other people working on the project.
Or, it might mean that the coder is trying to expand the feature set of the code. If you subscribe to the Linux philosophy, the broader the scope of functionality, the worse the code will get.
My point with all this is that "amount of effort" doesn't tell us anything about a code base. A great coder will do something in 10 commits that a terrible coder will do in 100.
The best metric I can think of right now is "how many users are touching this code". That tells you how useful the code is and how much work it is saving people. That's the core purpose of software: doing some work to save a much larger amount of work in the future. How do we measure that instead?
You're absolutely right, hits-of-code won't tell us anything about the quality of code, just the amount of effort programmers put into its creation. The code may be complete crap, but hits-of-code will be high. This metric is not an indicator of quality - not at all.
However, if all programmers in the team has similar skills and experience, they will create similar quality (well, on an average). In this case, hits-of-code can be used to predict project budget, schedule, etc.
> In this case, hits-of-code can be used to predict project budget, schedule, etc.
No, it can't, unless you're doing the same work over and over. The variable of "what is the code supposed to do?" completely eliminates the value of SLoC or HoC.
If I learn my HoC metric for a payment module, that doesn't tell me a single thing about how much time or effort it would be to rewrite a messy controller or add an API call or build an invoice module.
Not all evidence is useful to gather. This particular evidence is potentially damaging because it gives you an unrealistic basis for predictions.
The Agile method for estimating scheduling works moderately well (breaking things up into small chunks). But Agile is based entirely on the idea that estimating a coding schedule is impossible.
I personally have always used my gut to tell me how long something will take, and then I double it. I have a friend who quadruples it. That method is about as accurate as anything, takes a few minutes at the most, and often results in under-promising and over-delivering.
When you start to create that payment module, you can predict its complexity. You have an experience of creating software, including payment modules. You can say that the module will be 1500 SLoC in size. This is what COCOMO prediction mechanism is based on, the SLoC metric.
I'm saying that this metric is wrong. And almost everybody agrees with this.
But HoC metric is perfectly suitable for such a prediction. You can say that this payment module will take 50000 HoC of my effort. And then you track performance based on this number. And you can estimate costs. Just like COCOMO, but using HoC.
We're using this metric over the last year but didn't give it this name. We're just getting this stats from git to measure the amount of efforts we spend on the code.. So, we'll try your ruby gem, why not :)
Trying to quantify the quality of a code base is pointless, impossible, or both.
Consider this. A perfect piece of code (from an engineering standpoint) has these characteristics:
If you make these assumptions, hits-of-code indicates poor quality. It shows that the coder introduced bugs, failed to foresee what the code would need to do, or just didn't write it concisely or efficiently enough.But because we'll always have to fix bugs and modify code, a more realistic set of characteristics is this:
It's a completely different list, but hits-of-code still might indicate poor quality. It might mean that the coder is constantly refactoring, which means there will be more bugs and more learning time for other people working on the project.Or, it might mean that the coder is trying to expand the feature set of the code. If you subscribe to the Linux philosophy, the broader the scope of functionality, the worse the code will get.
My point with all this is that "amount of effort" doesn't tell us anything about a code base. A great coder will do something in 10 commits that a terrible coder will do in 100.
The best metric I can think of right now is "how many users are touching this code". That tells you how useful the code is and how much work it is saving people. That's the core purpose of software: doing some work to save a much larger amount of work in the future. How do we measure that instead?