There are always some methods, classes or helpers you don’t find in your programming language, which would be useful to save boilerplate code or needed a lot in your programme. Now you are confronted to decided whether you implement this particular function yourself ( do-it-yourself ) or use a third party library ( don’t-repeat-yourself). I sometimes have awesome discussions with my boss, which approach we should use. The following is a comparison of both approaches with pros and coins.

DRY | Don’t-Repeat-Yourself

The main question is, why should I invent the wheel again. There are a lot of good libraries out there like Google Guava, Apache Commons and many others for more specialized use cases. Before taking a closer look to the library, we consider the following points

• When was the last source code update? Is the libary still maintained?
• Are there documentations and examples how to use the library
• Is there any kind of community

This part of a list described on Java Code Geeks. If we cannot satisfy at least 2 of the 3 points, we won’t choose the library and look for a different one. Now we would take a closer look at our library, read tutorials and the documentation and use the one function we where missing in our current library/language set. Often we do this by writing tests assuring the library does what we want it to do. This is crucial as if you update the library all your functions will be tested. Joda Datetime for example implements some RFC standards, which is pretty awesome. However you have to read the RFC to know exactly what is going on or you just test the methods you need.

Lets summairze the benefits from using a third party library

• Less development time
• Pretested functionality
• Less maintainance support

DIY | Do-It-Yourself

Sometimes you just need this one little method. However it shippes with a big library with features you never even heard of. This library satisfies every standard you set, but it is too big (no matter if you mean size, features or maintaince overhead). Even if the library isn’t too big, maybe you just don’t like it in case of API or code style. So you start to write it yourself and it will be part of your product.

Summarize

To summarize the different aspects in a single table:

Task	DRY	DIY	Description
Development	Learn the API	Write API	The more complex the library and the worse the documentation the harder it’s to learn an API than to write your own
Tests	Test library API you use	Test your own Implementation	Always need them
Maintainance	Community Support	Alone	When you use an 3. party open source library you should give something back
Happiness	a bit	even more	“Developers are lazy, but they don’t want to read API docs. Writing code on their own makes them even more happy sigh”