3rd party dependencies: yes or no?
A question that always arrives when working on code projects is whether or not it's wise to add a 3rd party dependency. It has the benefit of moving fast but the risk of adding a dependency that might end up not being maintained anymore.
I used to work at an agency in which we had to move fast. Customers paid us per hour, based on estimations developers made. Like we often didn't have time to write tests, we also didn't have time to write solid solutions ourselves.
Picking a 3rd party dependency is tricky. It's important to estimate whether the library is well maintained, contains quality code, and is likely to last for the long-term future. An undocumented, not so old and unpopular library is probably not something you want to depend on.
At WeTransfer, we have a different approach to finding solutions to our problems. We use popular frameworks as an inspiration, and we always consider using them. However, if we find it possible to write a little extension ourselves, we would always prefer to go that route. Frameworks often come with much more features than needed, and you always have to wait for contributors to keep the framework up to date. Unless you want to contribute yourself, obviously, by writing your own solution, you know for sure you need to maintain it yourself, but you're also aware of what it implies, and you can keep the code to a minimum.
If a 3rd party dependency is exactly what you need, definitely consider using it. The point I want to make is that it should be a well-considered decision and not just a quick answer to a problem.
This week, I'm demonstrating such a case by implementing a relatively small piece of code to solve dependency injection instead of integrating a larger popular 3rd party framework.
Enjoy this week's SwiftLee Weekly! |
