Developers love shiny things. We love to play with new toys, try out new APIs, and libraries. If it was featured on Hacker News, we will find a way to shoe-horn it into a project, just to say we used it.
Therein lies one of the problems with developers. In our race to implement the shiny, we rarely stop and answer the question “Just because you can, should you?” The answer is obvious to us, “Yes, I should BECAUSE I can!” This is a perfectly acceptable answer for personal projects. Heck, that is what personal projects are for.
In production systems though, careful thought should be put into each and every library you bring into the system.
- Is it absolutely necessary?
- Is it the best tool for the job?
- Do we have a reasonable level of confidence in the code?
Look at why the library or project was created? Was it created for systems like yours? Was it created for systems that operate on a similar scale as you? This is commonly known as “You are not Facebook.” If a project or library was created for Facebook so that facebook can solve a problem at the scale they operate, it is most likely a very bad fit for your project unless you operate new the same levels of scale.
Sometimes, the shiny is the right answer and you use it and everybody is happy. That’s great, as long as you’ve done the research to prove that it is the right answer.
Spending more time thinking about the goals of your project will help you spend less time chasing the shiny.
Until next time,
I <3 |<