Question

A few years ago, we needed a C++ IPC library for making function calls over TCP. We chose one and used it in our application. After a while, it became clear it didn't provide all functionality we needed. In the next version of our software, we threw the third party IPC library out and replaced it by one we wrote ourselves. From then on, I sometimes doubt whether this was a good decision, because it has proven to be quite a lot of work and it obviously felt like reinventing the wheel. So my question is: are there disadvantages to code reuse that justify this reinvention?

Was it helpful?

Solution

The biggest disadvantage (you mention it yourself) by reusing third party libraries, is that you are strongly coupled and dependent to how that library works and how it's supposed to be used, unless you manage to create a middle interface layer that can take care of it.

But it's hard to create a generic interface, since replacing an existing library with another one, more or less requires that the new functionality works in similar ways. However, you can always rewrite the code using it, but that might be very hard and take a long time.

Another aspect is that if you reinvent the wheel, you have complete control over what's happening and you can do modifications as you see fit. This can be completely impossible if you are depending on a third part library being alive and constantly providing you with updates and bug fixes. On the other hand, reusing code this way enables you to focus on other things in your software, which sometimes might be the thing to do.

There's always a trade off.

OTHER TIPS

I can suggest a few

  1. The bugs get replicated - If you reuse a buggy code :)

  2. Sometimes it may add an additional overhead. As an example if you just need to do a simple thing it is not advisable to use a complex BIG library that implements the required feature.

  3. You might face with some licensing concerns.

  4. You may need to spend some time to learn\configure the external library. This may not be effective if the re-development takes a much lower time.

  5. Reusing a poorly documented library may get more time than expected/estimated

P.S. The reasons for writing our own library were:

  • Evaluating external libraries is often very difficult and it takes a lot of time. Also, some problems only become visible after a thorough evaluation.
  • It made it possible to introduce some features that are specific for our project.
  • It is easier to do maintenance and to write extensions, as you know the library through and through.

It's pretty much always case by case. You have to look at the suitability and quality of what you're trying to reuse.

The number one issue is: you can only successfully reuse code if that code is GOOD code. If it was designed poorly, has bugs, or is very fragile then you'll run into the same issues you already did run into -- you have to go do it yourself anyway because it's so hard to modify the existing code.

However, if it's a third-party library that you are considering using that you don't have the source code for, it's a little different. You can try and get the source if it's that kind of library. Some commercial library vendors are open to suggestions and feature requests.

The Golden Wisdom :: It Has To Be Usable Before It Can Be Reusable.

If your code relies on external resources and those go away, you may be crippling portions of many applications.

Since most reused code comes from the internet, you run into all the issues with the Bathroom Wall of Code Atwood talks about. You can run into issues with insecure or unreliable borrowed code, and the more black boxed it is, the worse.

Disadvantages of code reuse:

  • Debugging takes a whole lot longer since it's not your code and it's likely that it's somewhat bloated code.
  • Any specific requirements will also take more work since you are constrained by the code you're re-using and have to work around it's limitations.
  • Constant code reuse will result in the long run in a bloated and disorganized applications with hard to chase bugs - programming hell.
  • Re-using code can (dependently on the case) reduce the challenge and satisfaction factor for the programmer, and also waste an opportunity to develop new skills.

It depends on the case, the language and the code you want to re-use or re-write. In general I believe that the higher-level the language is, the more I tend towards code reuse. Bugs in higher-level language can have a bigger impact, and they're easier to rewrite. High level code must stay readable, neat and flexible. Of course that could be said of all code, but, somehow, rewriting a C library sounds less of a good idea than rewriting (or rather re-factoring) PHP model code.

So anyway, these are some of the arguments I'd use to promote "reinventing the wheel".

Sometimes it's just faster, more fun, and better in the long run to rewrite from scratch than having to work around bugs and limitation of a current codebase.

Wondering what you are using to keep this library you reinvented?

  1. Initial time for create a reusable code is more expensive and time cost
  2. When master branch has an update you need to sync it and deploy again
  3. The bugs get replicated - If you reuse a buggy code
  4. Reusing a poorly documented code may get more time than expected/estimated
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top