Why modifying vendor code is a bad idea

 

Writing software for production is one of the toughest endeavors a person can take. The fact of the matter is that more than often we are tempted to simply look up an existing solution and modify its source for our own needs.

At the surface of it this seems quite desirable, maybe even a good practice, in reality going down that path is likely to take you into a world of horrors. Here is why.

Writing reusable code is hard

To fully understand this concept we must take into account the rule of three. This rule states that:

  1. It is three times as hard to build reusable components as single use components
  2. Reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.

Now of cause this are not hard rules but they provide an easy to recall rule of thumb and its lessons are intuitively clear.

A truly general solution solves not only the general problem but also the specific solution of which it was intended to solve, as such tests for it must be written to this specification.

With this knowledge in mind how much are you willing to bet the solution you wish to modify was written as a general reusable solution?

Specific solutions exclude other solutions

With the idea that the solution your are about to modify was probably written to solve a specific solution, we must now think of the impact the design decisions made by its maintainers has on its ability to solve other problems.

As it turns out there isn’t a best design solution for a problem but rather each designer would probably land on their own unique and correct design for solving the problem at hand. This would mean to modify the existing design would need you not only to understand the problem but the philosophy on which the design solution was chosen.

In iterative methodologies (Agile, XP etc) this is especially a problem since simple designs are encouraged and over time they evolve to meet the complex needs of the final solution. The evolution process is probably not documented and maybe hard to know of its existence let alone comprehending it.

Understanding the solution

Given that we now have a specific solution it may be particularly hard to understand it without knowing the specific problem it was intended to solve. To the designers of the solution, the problem is probably painfully obvious, however to you the outsider, this is very rarely the case.

Furthermore you may find that as time went by even the original designers forgot how the solution actually works! If this phenomena sounds strange, try looking at code you wrote a couple of months ago.

Documentation

Or in our case, lack of it. While the virtues of proper documentation are preached at every corner of the software boulevard, its adherents are scarcely anywhere to be found!

If you know nothing else about the project, you can still gamble on inadequate documentation, this exacerbates all the problem mentioned above.

Even more interesting, you, the modifier of the code are not likely to document your changes either further complicating things down the road.

Later releases

Unless the project you are thinking of modifying is a dead project. The maintainers are probably fixing old bugs and adding new features all the time.

It goes without saying that this changes are likely incompatible with your own version so you may need to redo the work all over again whenever a new release comes out.

So what to do?

Reusing and modifying large components will be a problem in the foreseeable future. However some actions you can take to at least gain some benefit out of existing software include:

  • Reuse only software meant for reuse. An example of this would be packages and libraries
  • Do not modify the code, instead write an adapter to interface the package and your code
  • If you need to change more than 20% of the code, rewriting it is likely to be cheaper
  • Use a dependency manager
  • Always write integration tests and run them every time a vendor does a release
  • Whenever possible, use packages with developers of some repute

Do you have any advice on reusing code? Talk to us on the comment section below

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Published by

jchencha

API Engineer