The title is borrowed from an economics article by Art Carden, which is of no further relevance to this post. Interesting read though, yes?
I’m enjoying the discussion in the iOS Developer Community™ about dependency of app makers on third-party libraries.
My main sources for what I will (glibly, and with a lot of simplification) summarise as the “anti-dependency” argument are a talk by Marcus Zarra which he gave (a later version than I saw of) at NSConference, and a blog post by Justin Williams.
This is not perhaps an argument that is totally against use of libraries, but an argument in favour of caution and conservatism. As I understand it, the position(s) on this side can be summarised as an attempt to mitigate the following risks:
- if I incorporate someone else’s library, then I’m outsourcing my understanding of the problem to them. If they don’t understand it in the same way that I do, then I might not end up with a desired solution.
- if I incorporate someone else’s library, then I’m outsourcing my understanding of the code to them. If it turns out I need something different, I may not be able to make that happen.
- incorporating someone else’s library may mean bringing in a load of code that doesn’t actually solve my problem, but that increases the cognitive load of understanding my product.
I can certainly empathise with the idea that bringing in code to solve a problem can be a liability. A large app I was involved in writing a while back used a few open source libraries, and all but one of them needed patching either to fix problems or to extend their capabilities for our novel setting. The one (known) bug that came close to ending up in production was due to the interaction between one of these libraries and the operating system.
But then there’s all of my code in my software that’s also a liability. The difference between my code and someone else’s code, to a very crude level of approximation that won’t stand up to intellectual rigour but is good enough for a first pass, is that my code cost me time to write. Other than that, it’s all liability. And let’s not accidentally give a free pass to platform-vendor libraries, which are written by the same squishy, error-prone human-meat that produces both the first- and third-party code.
The reason I find this discussion of interest is that at the beginning of OOP’s incursion into commercial programming, the key benefit of the technique was supposedly that we could all stop solving the same problems and borrow or buy other peoples’ solutions. Here are Brad Cox and Bill Hunt, from the August 1986 issue of Byte:
Encapsulation means that code suppliers
can build. test. and document solutions to difficult user
interface problems and store them in libraries as reusable
software components that depend only loosely on the applications that use them. Encapsulation lets consumers assemble generic components directly into their applications. and inheritance lets them define new application specific components by inheriting most of the work from generic components in the library.Building programs by reusing generic components will seem strange if you think of programming as the act of assembling the raw statements and expressions of a programming language. The integrated circuit seemed just as strange to designers who built circuits from discrete electronic components. What is truly revolutionary about object-oriented programming is that it helps programmers reuse existing code. just as the silicon chip helps circuit builders reuse the work of chip designers. To emphasise this parallel we call reusable classes Software-ICs.
In the “software-IC” formulation of OOP, CocoaPods, Ruby Gems etc. are the end-game of the technology. We take the work of the giants who came before us and use it to stand on their shoulders. Our output is not merely applications, which are fleeting in utility, but new objects from which still more applications can be built.
I look forward to seeing this discussion play out and finding out whether it moves us collectively in a new direction. I offer zero or more of the following potential conclusions to this post:
- Cox and contemporaries were wrong, and overplayed the potential for re-use to help sell OOP and their companies’ products.
- The anti-library sentiment is wrong, and downplays the potential for re-use to help sell billable hours.
- Libraries just have an image problem, and we can define some trustworthiness metric (based, perhaps, on documentation or automated test coverage) that raises the bar and increases confidence.
- Libraries inherently work to stop us understanding low-level stuff that actually, sooner or later, we’ll need to know about whether we like it or not.
- Everyone’s free to do what they want, and while the dinosaurs are reinventing their wheels, the mammals can outcompete them by moving the craft forward.
- Everyone’s free to do what they want, and while the library-importers’ castles are sinking into the swamps due to their architectural deficiencies, the self-inventors can outcompete them by building the most appropriate structures for the tasks at hand.
