Does the idea of a code library fulfilling a significant portion of a freelance project sound appealing? It’s ok, you can be honest and say ‘yes’. When I started out on my freelance journey, any time I came across a large feature request the first task I’d do was check to see if there was a code library that took care of the requirement. In the development world, code libraries like these are called silver bullets.
However, as appealing as it may sound for a plugin or library to take care of the lion share of a project, it’s been my experience that this approach ends up taking longer to implement than simply building the components from scratch.
Let’s start off with a practical case study. A few years ago I took on a fleet management project. The set of requirements included features such as:
After starting the project I started to research code libraries that would work as silver bullets and take care of the key features. After a few days I came across the RubyGem called
rails admin. The rails admin gem is pretty impressive. It includes features such as:
As you may have noticed, this code library looks like it fits nicely with the set of requirements for the project I had.
I quickly went to work building out the application. And I integrated the rails admin gem as a cornerstone component of the project. The client was ecstatic during the demo. They absolutely love the application and they were shocked I was able to build the app so quickly.
So what was the problem? The issues started when the client started to ask for new features. After testing the application out for a few weeks they came back with feature requests such as:
Each of these new features are relatively common requests for a fleet management system. There was just one problem. Because I built the entire application around the rails admin code library I was limited to the features that the gem offered. And this was a problem because rails admin turned out to be incredibly difficult to modify.
In fact, after several weeks of tedious work I came to the conclusion that it would take less time to build the entire system from scratch as opposed to customizing the gem itself. So the end result was that I wasted quite a bit of time and the project was delayed. All because I thought a single silver bullet code library was going to be able to take care of a significant portion of the application.
So does this mean that I’m suggesting that you stay away from code libraries entirely? No, not at all! Part of the reason why freelancing is possible (and affordable for clients) is that you don’t have to create 100% of an app’s functionality from scratch.
Instead I’ve learned to be selective about the code libraries that I integrate. Let’s look at a couple of the code libraries that I regularly use on projects:
Do you notice how these code libraries operate like helper libraries for specific features? My rule for integrating code libraries into projects is that I pick out packages that assist with small elements of a project. And I shy away from silver bullets that promise to take care of large portions of a project’s functionality, but are difficult to customize.