
Hits-of-Code Metric Instead of SLoC - yegor256a
http://www.yegor256.com/2014/11/14/hits-of-code.html?2014-45
======
smt88
It's better than SLoC, but it's still not good.

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?

~~~
yegor256a
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.

~~~
smt88
> 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.

~~~
yegor256a
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.

------
bibonix
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 :)

------
JohnHaugeland
Biassed in favor of people who write lots of bugs and people who commit in
smaller batches.

