This article is written with the findings from an
investigation that I participated in and is still ongoing. It does not explain
everything. The investigation has not concluded yet because the root cause has
not been found yet. I have not heard any other similar case so far and I have
had difficulty in outlining the defect but the learnings from the efforts stand
clear.
A specific java code was packaged as a jar because it had a
very narrow purpose and needed to be reused with applications from different
sources. This jar happened to be a fat
jar which is a term to say that it contained all the dependencies needed to run
its code. The jar worked well whenever the applications were run. However, it
was inconvenient to copy it to each repository manually. The time-tested way of
bringing in jars like these has been to use one or the other distribution
repository.
The code was therefore forked which is a term used to denote
another location where a copy of the code would be modified. The changes could
include a rewrite and some trimmings so that the newer code was lean and
mean. The forked code would then be
uploaded to a repository and consumers could then refer to it by name in the
dependency and it would all work well with the elimination of the unnecessary
step to bring it in any other way.
It turned out that this effort did not really work the way
as intended. The reason for the failure is still under investigation. The code
was supposed to be the same and it was reviewed to ensure that no defects were
introduced. It had test cases that seemed to work. Yet the code was not working
for users. If all the factors that
played out with the previous code were determined, the current effort would
have panned out. This was the key learning and is often referred to in the
industry as regression tests. These tests are written with the goal of keeping
the behavior of the current code the same as that of the previous irrespective
of the changes made to the current. Somewhere, there was a regression
introduced and it was manifesting as a failure.
The nature of the software development is that it is always
focused on functionality. However, it is the value that all the assets that
guarantee the non-functional aspects of the code that determine how easy it is
to use the code. The functional and non-functional aspects are both needed from
any implementation but while the former has the bulk of the emphasis on the
maker, it is the latter that determines the appreciation.
No comments:
Post a Comment