5

I will start with one, which however did not work the way I wanted.

Vendor Evaluation:
In the beginning of the project, we spent some time to do a survey of existing open-source libraries that can be used as building blocks for a larger library. Despite our efforts, there were a number of libraries which we did not come across until several months into the project. Had we found out those missed libraries earlier, we might have made our design decisions differently.

Architecture Compatibility:
It was understood from the very beginning that no single library could have satisfied all requirements, so several existing libraries are needed, along with some custom implementation to fill the gaps. These libraries would have to be wrapped into a single architecture so that the users will not need to know the internal construction of the library. Efficiency (in multiple aspects; can be summarized as "no CPU time, RAM nor Disk space can be wasted") was the main driving force in the architectural design; so the wrappers need to be equally efficient. In the beginning we did not know which open-source library would be compatible with the design (in the sense that the wrapper does not introduce any inefficiency of its own), as that would have required some pioneering work to find out.

Code quality:
One of the open-source library was about 20 years old. Another library was about 10 years old. In the prevailing thinking of open-source library, the older library is supposed to be more stable and have fewer bugs. Eventually we discovered that the opposite was true, and we ended up having to fix a number of bugs in the older library.

My original hypothesis is that "Does it take a lot of intelligence to not succumb to it? Does it take a lot of experience?" but after reviewing the project, I came to the conclusion that software reuse is like matchmaking - any notion of "missed opportunity" occurs naturally due to chance, and no amount of intentional effort will reduce missed opportunities.

What does it take to not succumb to Not Invented Here syndrome, in order to achieve the highest degree of software reuse and at the same time satisfying the software requirements perfectly?

Added (2010/12/18)

One of the reason we missed a good candidate library was that it was ruled out very early in the process. When there are more than 10 libraries in the initial list, there is some pressure to find rules that can quickly eliminate some of the candidates, because otherwise we would have spent too much time analyzing (analysis paralysis). However, this fast-track elimination caused the undesirable effect of rejecting one good library. (just like hiring?)

gnat
  • 21,213
  • 29
  • 113
  • 291
rwong
  • 16,878

4 Answers4

6

Joel wrote a nice article on this:

http://www.joelonsoftware.com/articles/fog0000000007.html

As a quick summary, if it's part of your core business, write it yourself, if not buy it.

BlackICE
  • 2,425
2

I will typically opt for established, well tested and documented libraries provided that:

  • Licensing terms are agreeable and compatible with everything else I'm using
  • The library is actively maintained

In your case, it looks like you stumbled across some bits that simply weren't maintained any longer. That doesn't mean the code was not useful, if it provided you with a good starting point to accomplish your goals .. it just means that more effort than what was anticipated had to go into using it. Does that effort exceed what would be required to just write the library from scratch? If so, you probably made a bad call. If not, it saved you time and money.

I am fortunate enough to work only with open source UNIX like operating systems, so for me it is simply a question of what gets me to the final goal with the least amount of resistance, while not compromising on the project's design principles.

Additionally, I think every programmer has a tool box with lots of shelves in it. The libraries that you just fixed, for instance, can probably be re-used .. thus increasing their value to you in the long term.

That being said, I'm currently in the process of re-inventing a few wheels .. but only because the effort it would take to work around what I don't like in what exists exceeds the effort it would take to implement something on my own. For instance, you might be coding to a very specific architecture .. and could do VERY well without a bunch of portability kruft.

I'm well known for going a little slow initially, while taking ample time to make sure I won't regret today's decision a few months from now. If I strongly suspect that I'll regret not just biting the bullet and implementing something from scratch, I'll happily do it.

  • "because the effort it would take to work around what I don't like in what exists exceeds the effort it would take to implement something on my own" - I think this is the key concern here. Code reuse isn't a value in itself, it's a way to save effort and improve maintainability. It's rare that rolling your own solution is easier than beating one or more existing libraries into submission for your use case, but it does happen. – Maciej Stachowski Oct 18 '23 at 09:32
0

Age of code is not as important as mainteinance of code. If nobody cares about it now, when did they?

If you pick up an uncared-for project, you end up - as you've experienced - maintaining it yourself. Search out those with a vibrant and large community. I have had good experience with Apache Jakarta projects and somewhat with Eclipse projects, plus several individual projects.

0

I had a team member who was adamant that we should write our system (a 3D engine) from scratch despite the fact that we had identified an engine that the team was familiar with and would mostly do. I took him aside and ask him if he was ready to take full responsibility for the failure of the project if he was unable to deliver his engine on time. He was not.

Henry
  • 2,020