Cui bono? Or the art of code reusing

Cui bono? Or the art of code reusing

Share it!Share on FacebookTweet about this on TwitterGoogle+Share on LinkedInEmail to someone
It is possible for shoemakers to ask themselves whether their art can be applied to make a clog.

It is possible for shoemakers to ask themselves whether their art can be applied to make a clog. They might then come to the conclusion that the recipient of their art will still be a foot after all and, therefore, it cannot make much of a difference. It is likewise possible the customer questions the shoemaker on that subject by saying: “It will be for a foot, how different could it be?” The shoemaker will answer to that according to their judgment and know-how: “It depends on the foot”.

The holy grail of reuse can also apply to the computer science field. There is a tendency to believe that similarity is a synonym for equivalence and any opinion against this concept is a clear sign of rebellion. “Is it that my feet are that different?” From a pragmatic point of view, we should start by focusing on the applications that are being developed and ask ourselves whether their code is really similar and, if so, which similarities they share; whether it is worth the time spent to adapt the code; and whether the fact of constantly readapting the code entails more effort than the actual benefits of rethinking and improving it.

One of the greatest advantages of computer science is its unique business model: it had never been so easy to replicate the same product. Any business model would be delighted to come up with a new bespoke product just by copying and pasting. However, the overuse of this possibility might have turned out to be the biggest downside.

It is reasonable to think that a medical application does not have a lot in common with an industrial one and, in fact, it is rather unlikely that both apps share any part of their code. There might be a chance if two applications were related to the medicine field but, taking into account the wide range of medicine branches, the effort might be slightly deceitful. Maybe the best examples would be those referring those features that do not depend on the nature of the application. For example, the ability to send an email will remain the same no matter which application is sending it.

It is true that some code can be reused. As a matter of fact, reusing is desirable, but not a mandatory rule that needs to be obeyed as if it we were talking about the philosopher’s stone. Lead can sometimes be useful and gold not that valuable if lead is applied to its best potential.

The concept itself, the fact of creating something new by using something already built, seems quite confusing. Therefore, under this assumption, how much code can actually be reused? This philosophy, which has many advocates, seeks a complicated commitment between the corporate advantages and the intangible and underestimated technical advantages that end up being noticeable in the long run. One of the architectures to have best expressed this concept is probably SOA, but even SOA currently tends to be simplified to its minimum expression through microservices in order to preserve the loyalty to its own philosophy.

Reusing sometimes falls into the trap of its own definition. The underlying question here is not whether to embracing the holy grail of reusing, but to distinguish when it is more advisable to create rather than reuse, when reusing provides the expected benefits, and when creating provides significantly more benefits.

Josu Uribe

Use of cookies

This site uses cookies for you to have the best user experience. By continuing to browse this website you accept their use and agree to our cookies policy. Learn more about our cookies, following this link