|
This is one of those mantras that I lived by when I got out of college, and then found that the reality was far more complicated than I initially believed. There're costs and benefits both to implementing something yourself and to using an off-the-shelf solution. It's a given that if you do something yourself, it will take 3 times as long as you expect, and you will be finding, tracking down, and fixing bugs long after you thought you'd be "done". And then if you bring in other people to help you, they'll all have to go through the same process. But using off-the-shelf solutions has hidden costs too. Abstractions leak; that 3rd-party library never completely shields you from the complexity it purportedly solves. There may not be docs, or they may be incompletely specified. You'll probably have to spend some time customizing it, and your customization code may often end up more convoluted than just reimplementing from scratch. You'll probably run into incompatibilities between different libraries. The libraries may themselves have bugs that you have to dig in and fix. Worse, reliance on off-the-shelf solutions often warps your product so that it fits the solutions you have available. ("When all you have is a hammer, everything looks like a nail.") As much as people say that they'll figure out the problem first and then pick solutions to solve it, the choice of solution then feeds back into the types of additional features you can add. If you decided to use an RDBMS early in development and then find you want to add, say, clustering of related items where "related" is defined by a fuzzy matching function, you'll likely say "This is too hard" and fall back using an exact match, one that can easily be stored in a relational table. Users suffer. Obviously, a blanket rule of DON'T PROGRAM is wrong, because many successful websites throw away all the off-the-shelf solutions and write their own. Google's probably the most obvious one. I'd amend it to "Carefully consider the infrastructure you'll be using, and only reach for the third-party solutions when they save you significant time and complexity over doing it yourself." |
Consider keeping such a chunk of code around only long enough to get the product shipped and paying for itself. At that point, make an attempt to justify keeping it around, especially after seeing how it fits into the big picture of your product.