Hits-of-Code Metric Instead of SLoC
yegor256.com
yegor256.com
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
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
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?
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.
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.
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.