Object-oriented programming and third party dependencies
One of the strengths of object-oriented programming is code reuse. Along the lines of:
Organize your code in objects and pack your objects into modules. When needed import your module and inherit data and behaviour from the classes in the module.
In the 90’s it sounded like the panacea to all the problems of software developers. To some extent it still is.
In the meantime open source became huge, thanks mostly to GitHub, and we now have millions of libraries/modules/packages ready to be imported and reused in our projects. Heaven, right? Except … they are all dependencies.
The second I import one of those in my project I have to be ready to maintain it in the future. The author might abandon it to jump on a new project, or just deem it not worth the effort. If I am working on a prototype, with mostly throwaway code, that might not be a problem. If I am building a product meant to work in the long run, I should be ready to maintain both my code and the third party libraries I pull in.
And so I am at an impasse.
There’s lots of interesting libraries out there, which I could use to speed up the development of my project (at least in the beginning) but they also can become a big commitment in the long run. I feel a bit like a kid in a candy store, and my parents are telling me that candies can be bad for my teeth.
How do I reconcile this?
I don’t. I compromise, much like with candies :) If I eat a few I brush my teeth longer than usual that day.
If you are an agency, you bill by the hour and have clients with a good budget you can definitely afford to avoid any third party dependencies and have full control over your code base.
If you mostly write prototypes and your client is onboard with your choices you can go all in with third party dependencies, to speed up the development and get to the working prototype quickly.
What if you are in the middle? With products that are meant for the long run but the budget is not stellar at the moment? As said, I compromise. I try to not “get in bed” with big frameworks and pull in only what it’s strictly needed. For example I don’t use any JSON parsing/mapping library and go with pure vanilla code for those tasks.
I try to pull in only small components, small as in my Snapping Slider. It does just one thing, it snaps to certain values when dragged. If you had to build this you’d probably need 1 or 2 hours. That’s why it’s not a big commitment to pull it in a project. Should you need to rebuild it from scratch in the future, you know it’s not a huge deal.
For example in the Podrover iOS app I have only three dependencies:
They are so few that I didn’t even bother creating a Cocoapods/Carthage file. And I know I can rebuild them in case GitHub disappeared tomorrow.
We need more small components like these. It would definitely simplify the search and ease the commitment to maintain future versions if needed.
For example, while building Podrover, I couldn’t find a UIButton that (when tapped) would:
- get disabled and show a spinner in the middle
- re-enable and hide the spinner after an operation was completed.
I had to build it. Now I need to polish it a bit and then I’ll release it on GitHub.
Conclusion
Third party dependencies are like candies. Too many are detrimental, but some here and there don’t hurt a lot, as long as you keep them under control. And the smaller, the better.