My recent experience mirrors the Rails/Basecamp history.

While working on the File_MARC proposal for PHP’s PEAR package repository, I initially created a basic linked list as part of the File_MARC package. I recognized that it could be its own package, but to be honest I was reluctant to go through the rigorous PEAR package proposal process for both File_MARC and a linked list package at the same time. Especially when File_MARC depends on the linked list package, so a hold-up in approval for the linked list package would delay File_MARC’s birth as well.

After a few weeks, I realized that I might as well split the linked list off into its own package as it was likely that a) the linked list package would be of much more general interest than File_MARC, and therefore more likely to have its rough edges (ahem, “bugs”) worn down by wider usage — thereby benefiting File_MARC and 2) by making it a separate package, it would force me to develop, test, and document the linked list functionality much more thoroughly than if it remained a part of the File_MARC “mud”. I’m convinced the results will be worth the extra effort.

Once I factored out the linked list into its own package, I realized that I could go a step further and refactor the doubly-linked list into a singly-linked list as a base class and reimplement the doubly-linked list as a simple extension to the singly-linked list. Benefit to the users, who can just choose a singly-linked list if their application doesn’t need the overhead of being able to traverse the list in reverse, and benefit to the development team (me) because of the code reuse.

So yes, nice little reusable packages are good.