[ACCEPTED]-How do you decide whether to use a library or write your own implementation-coding-style

General Decision

Before deciding on what to use, I will create 41 a list of criteria that must be met by the 40 library. This could include size, simplicity, integration 39 points, speed, problem complexity, dependencies, external 38 constraints, and license. Depending on the 37 situation the factors involved in making 36 the decision will differ.

Generally, I will 35 hunt for a suitable library that solves 34 the problem before writing my own implementation. If 33 I have to write my own, I will read up on 32 appropriate algorithms and seek ideas from 31 other implementations (e.g., in a different 30 language).

If, after all the aspects described 29 below, I can find no suitable library or 28 source code, and I have searched (and asked 27 on suitable forums), then I will develop 26 my own implementation.

Complexity

If the task is relatively 25 simple (e.g., a MultiValueMap class), then:

1. Find an existing open-source implementation.
2. Integrate the code.
3. Rewrite it, or trim it down, if it excessive.

If 24 the task is complex (e.g., a flexible object-oriented 23 graphing library), then:

1. Find an open-source implementation that compiles (out-of-the-box).
2. Execute its "Hello, world!" equivalent.
3. Perform any other evaluations as required.
4. Determine its suitability based on the problem domain criteria.

Speed

If the library is 22 too slow, then:

1. Profile it.
2. Optimize it.
3. Contribute the results back to the community.

If the code is too complex 21 to be optimized, and speed is a factor, discuss 20 it with the community and provide profiling 19 details. Otherwise, look for an equivalent, but 18 faster (possibly less feature-rich) library.

API

If 17 the API is not simple, then:

• Write a facade and contribute it back to the community.
• Or find a simpler API.

Size

If the compiled 16 library is too large, then:

• Compile only the necessary source files.
• Or find a smaller library.

Bugs

If the library 15 does not compile out of the box, seek alternatives.

Dependencies

If 14 the library depends on scores of external 13 libraries, seek alternatives.

Documentation

If there is 12 insufficient documentation (e.g., user manuals, installation 11 guides, examples, source code comments), seek 10 alternatives.

Time Constraints

If there is ample time to find 9 an optimal solution, then do so. Often there 8 is not sufficient time to write from scratch. And 7 usually there are a number of similar libraries 6 to evaluate. Keep in mind that, by meticulous 5 loose coupling, you can always swap one 4 library for another. Find what works, initially, and 3 if it later becomes a burden, replace it.

Development Environment

If 2 the library is tied to a specific development 1 environment, seek alternatives.

License

Open source.

10 questions ...

+++ (use library) ... --- (write own library)

1. Is the library exactly what I need? Customizable in a few steps? +++
2. Does it provide almost all functionality? Easily extensible? +++
3. No time? +++
4. It's good for one half and plays well with other? ++
5. Hard to extend, but excellent documentation? ++
6. Hard to extend, yet most of the functionality? +
7. Functionality ok, but outdated? -
8. Functionality ok, .. but weird (crazy interface, not robust, ...)? --
9. Library works, but the person who needs to decide is in the state of hybris? ---
10. Library works, manageable code size, portfolio needs update? ---

Some thoughts ...

If it is something that is small but useful, probably 10 for others, too, then why now write a library 9 and put it on the web. The cost publishing 8 this kind of small libraries decreased, as 7 well as the hurdle for others to tune in 6 (see bitbucket or github). So what's the criteria?

Maybe 5 it should not exactly replicate an existing 4 already known library. If it replicates 3 something existing, it should approach the 2 problem from new angle, or better it should 1 provide a shorter or more condensed* solution.

*_/fun

If it's a trivial function, it's not worth 5 pulling in an entire library.

If it's a non-trivial 4 function, then it may be worth it.

If it's 3 multiple functions which can all be handled 2 by pulling in a single library, it's almost 1 definitely worth it.

Keep it in balance

You should keep several criteria in balance. I'd 23 consider a few topics and ask a few questions.

Developing time VS maintenance time

Can 22 I develop what I need in a few hours? If 21 yes, why do I need a library? If I get a 20 lib am I sure that it will not cause hours 19 spent to debug and documentation reading? The 18 answer - if I need something obvious and 17 straightforward I don't need an extra-flexible 16 lib.

Simplicity VS flexibility

If I need just an error wrapper do I 15 need a lib with flexible types and stack 14 tracing and color prints and.... Nope! Using 13 even beautifully designed but flexible and 12 multipurpose libs could slow your code. If 11 you plan to use 2% of functionality you 10 don't need it.

Dig task VS small task

Did I faced a huge task and 9 I need external code to solve it? Definitely 8 AMQP or SQL operations is too big tasks 7 to develop from scratch but tiny logging 6 could be solved in place. Don't use external 5 libs to solve small tasks.

My own libs VS external libs

Sometimes is better 4 to grow your own library because it is for 3 100% used, for 100% appropriate your goals, you 2 know it best, it is always up to date with 1 your applications. Don't build your own lib just to be cool and keep in mind that a lot of libs in your vendor directory developed "just to be cool".

For me this would be a fairly easy answer.

If 16 you need to be cost effective, then it would 15 probably be best to try and find a library/framework 14 that does what you want. If you can't find 13 it, then you will be forced to write it 12 or find a different approach.

If you have 11 the time and find it fun, write one. You 10 will learn a lot along the way and you can 9 give back to the open source community with 8 you killer new bundle of code. If you don't, well, then 7 don't. But if you can't find one, then you 6 have to write it anyway ;)

Personally, if 5 I can justify writing a library, I always 4 opt for that. It's fun, you learn a lot 3 about what you are directing your focus 2 towards, and you have another tool to add 1 to your arsenal and put on your CV.

If the functionality is only a small part 33 of the app, or if your needs are the same 32 as everyone else's, then a library is probably 31 the way to go. If you need to consume and 30 output JSON, for example, you can probably 29 knock something together in five minutes 28 to handle your immediate needs. But then 27 you start adding to it, bit by bit. Eventually, you 26 have all the functionality that you would 25 find in any library, but 1) you had to write 24 it yourself and 2) it isn't a robust and 23 well document as what you would find in 22 a library.

If the functionality is a big 21 part of the app, and if your needs aren't 20 exactly the same as everyone else's, then 19 think much more carefully. For example, if 18 you are doing machine learning, you might 17 consider using a package like Weka or Mahout, but 16 these are two very different beasts, and 15 this component is likely to be a significant 14 part of your application. A library in this 13 case could be a hindrance, because your 12 needs might not fit the design parameters 11 of the original authors, and if you attempt 10 to modify it, you will need to worry about 9 a much larger and more complex system than 8 the minimum that you would build yourself.

There's 7 a good article out there talking about sanitizing 6 HTML, and how it was a big part of the app, and 5 something that would need to be heavily 4 tuned, so using an outside library wasn't 3 the best solution, in spite of the fact 2 that there were many libraries out that 1 did exactly what seemed to be called for.

Another consideration is security.

If a black-hat 18 hacker finds a bug in your code they can 17 create an exploit and sell it for money. The 16 more popular the library is, the more the 15 exploit worth. Think about OpenSSL or Wordpress 14 exploits. If you re-implement the code, chances 13 that your code is not vulnerable exactly 12 the same way the popular library is. And 11 if your lib is not popular, then an zero-day 10 exploit of your code probably wouldn't worth 9 much, and there is a good chance your code 8 is not targeted by bounty hunters.

Another 7 consideration is language safety. C language 6 can be very fast. But from the security 5 standpoint it's asking for trouble. If you 4 reimplement the lib in some script language, chances 3 of arbitrary code execution exploits are 2 low (as long as you know the possible attack 1 vectors, like serialization, or evals).