Quality vs popularity

21 Mar 2018 on
random

When validating library quality, we like to
take a look at some metrics like
the time of the last commit or the number of
stars as if those relate to quality.
It's the easiest thing to do, instead of
validating the quality by other means,
we go with the easiest approach
of following everybody else.

With this we save time, which means saving
money for our employers, but there is a price we pay.
It is not free. We risk choosing the popular
option instead of the better one.

What if instead of looking at the stars, we
focused on reading every library we included?
It's all open source so this is a great benefit
of it, being able to read the source code.

Easy, right?

Not really. Reason for this
is that we use the baterries included libraries,
popularly known as frameworks, which are large
in scope and that's what prevents us from reading the
source code in a reasonable amount of time.
Unfortunately those projects are usually more
popular than the smaller alternatives.

The larger the scope of a library, the more
it needs to be maintained, so the perceived
status of it is that it's being actively developed.
Meanwhile, the smaller libraries don't need
so much maintenance, so if we only look
at the time of the last commit as a metric
for determining the quality we'll go with
the larger one and we'll perceive the smaller
one as collecting dust.

If we used libraries that are focused on a single feature
more, we would end up having codebases that
are more easily understandable by a single person in
their entireties. [1]

We could say that the point of having
libraries is abstraction, which hides away
the nasty implementation details in a black
box. In my opinion, programmers need to know
at least the basics of how those black boxes
work internally in order to be able to
construct quality software with them. That's easier
with libraries with narrower scope.

The biggest risk of going of reading
source code of libraries to be included is investing
time in libraries we're not going to end up using.
Good practice for alleviating this risk is by
only considering small libraries. [2]

There are a lot of benefits from reading the source
code, so why not do it more often? Especially
when it comes to something as critical as deciding
if library should be used or not.

Niklaus Wirth writes that
a system that's not understood by a single person
in it's entirety shouldn't be built. Read more about
that in his excellent paper A Plea for Lean Software [1995].

Check out
a mirror of microrb.com
as a way of finding small libraries in Ruby community.