The Usefulness of Obsolete Libraries
Finnian Reilly
The Usefulness of Obsolete Libraries
In long lived software systems, the label obsolete is often interpreted as meaning no longer useful. In practice, this is rarely the case. Obsolete or deprecated libraries frequently continue to provide value in ways that are easy to overlook, particularly in mature ecosystems.
First, obsolete libraries often serve as informative exemplars of how dependencies are structured and exercised. Because they were written against earlier versions of an ecosystem, they can make dependency relationships explicit in ways that newer code no longer does. They may also provide coverage for features that are no longer used elsewhere, preserving working examples of behavior that would otherwise be untested or undocumented.
Second, obsolescence does not imply non functionality. Many deprecated libraries remain in active production use for long periods of time. A common example is the PayPal Button API, which, despite being officially deprecated, continues to operate reliably in real systems. In such cases, deprecation signals that the technology is no longer recommended for new development, not that it has stopped working or is unsafe to run.
Third, obsolete libraries often retain test suites that continue to serve an important role. Even if the libraries themselves are no longer evolving, their tests still exercise shared dependencies. When core libraries are refactored or modernized, these tests can act as regression checks, helping to ensure that changes do not silently break behavior that is still relied upon elsewhere.
In addition, obsolete libraries can function as historical records of architectural decisions. They capture design approaches, assumptions, and trade-offs made at a particular point in time. This can be valuable when trying to understand why certain abstractions exist, or why newer designs evolved in a particular direction.
Finally, keeping obsolete libraries available can reduce risk during modernization. They provide a stable reference point against which new implementations can be compared, both behaviorally and structurally. Removing them prematurely can make it harder to detect subtle regressions or to reason about compatibility with legacy systems.
For these reasons, obsolete libraries are often best viewed not as dead code, but as archival assets. Their value lies less in future development and more in verification, continuity, and understanding. In well maintained codebases, obsolescence marks the end of evolution, not the end of usefulness.
Liberty Lover
Clarification on my assessment of your PayPal SBM library
Hi Finnian,
I am reaching out directly to clear up a misunderstanding regarding my assessment of your PayPal SBM library. It seems my "SKIP" verdict has been interpreted as a critique of your implementation or code quality. I want to be clear: that is a conflation of two very different technical concerns.
The Context
My assessment was based strictly on API lifecycle, not your craftsmanship. When I looked at the library (PayPal Payments Standard Button Manager API, 52 classes), my reasoning was purely architectural:
Relevance (2026+): 0/5 — PayPal has officially deprecated this specific API.
Verdict: SKIP
Reason: Use PayPal REST API or Stripe instead.
Lifecycle vs. Quality
The "strawman" being circulated is that "deprecated" equals "poorly written." This is a false equivalence. A third-party API being deprecated by the provider is an external constraint that limits its future utility, regardless of how well you've implemented the Eiffel wrapper.
My job as an architect is to identify which dependencies are worth the long-term maintenance burden for my own project code an ecosystem of libraries. Here is how I’ve broken down the triage:
| Question | Answer | Why |
| Is your PayPal code well-written? | Probably yes | I haven't examined the internals; the quality wasn't the point of the triage. |
| Is PayPal SBM maintained? | No | PayPal officially deprecated it on their developer portal. |
| Should we adopt deprecated APIs? | No | It creates a maintenance burden with zero future utility. |
| Should we move toward modern APIs? | Yes | REST, Stripe, and Square are the current industry standards. |
Moving Forward
I am not saying your code is bad (in fact, I have clearly stated the opposite); I am saying the API it connects to is obsolete. If PayPal SBM were still a current, supported standard, the verdict would have been completely different.
This is simply pragmatic triage for 2026 and beyond. My goal is to ensure we are investing our collective effort into modern payment gateways (REST, Stripe, etc.) rather than maintaining bindings for services that PayPal itself is moving (and has moved) away from.
I hope this clarifies my position and makes it clear that this was an architectural decision, not a reflection on the quality of your work.
Best,
Larry
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/864c7a34-76ba-45ec-bc05-36c16bde00cc%40eiffel-loop.com.
Finnian Reilly
Many developers also maintain an “obsolete” or “archive” area at the class level, not only at the library level. I keep a dedicated folder of obsolete classes as an archive of interesting but ultimately unsuccessful ideas, and as a way of preserving code that may later be useful as a reference or starting point for a new implementation. Even when a particular abstraction proves less useful than hoped, it may still represent substantial design and implementation effort, and it can remain valuable in a documentary sense.
Such archives also provide a record of the routes taken and the detours explored. They can prevent a maintainer from repeating an unfruitful approach that has been forgotten over time, and they can shorten the path when revisiting an idea with better context or a clearer implementation strategy. In some cases, what failed originally was not the core idea, but its timing, its dependencies, or the surrounding constraints. Keeping the work makes it easier to resurrect or rework it later without starting from zero.
Ulrich Windl
Adobe Lightroom had a map feature where you could assign images to locations and show those in a map.
At some point in time Google decided to replace that API, making that part of Lightroom fail. Also a good argument against relying on any cloud service you cannot control yourself...
Of course it's hard to make any API correct on the first attempt.
Regards,
Ulrich