34

I am in a situation where I can use an open source JavaScript plugin to fulfill a task. But when I tried to use it,I found myself I have to redesign lot of things of what I already have done,and it adds a certain complexity, in my humble opinion, to the project. Whereas I can achieve the same task with a clean code I can craft myself, and without needing to change what I have done so far.

Should you opt for a library anyway in this situation (like for the sake of better quality code?)

Billal Begueradj
  • 1,305
  • 5
  • 16
  • 31
  • 3
    How are you measuring "quality". By the number of lines of code? Classes? Complexity? Maintainability? Resilience? – Laiv Oct 15 '18 at 06:40
  • 3
    The answer is NO, no matter what you consider quality or not. But if you provide us with your idea of quality, answers will address their reasoning to explain why the number of libraries don't improve what you consider quality. It's a mere matter of precession. As it's now, a simple NO will answer the question with no need of explanation. – Laiv Oct 15 '18 at 06:50
  • 4
    Not a direct answer to your question, but the idea that "this number" inevitably guarantees "better quality" flies in the face of acknowledging the difficulties of increasing code quality. There is no quick-fix to ensure quality. If there was, the problem wouldn't exist. Anyone who claims that a certain simple approach is the be-all-end-all solution is either (at best) overgeneralizing or (at worst) pushing their flawed idea as a truth. – Flater Oct 15 '18 at 07:13
  • 3
    What makes you think using the library would increase code quality? – Stop harming Monica Oct 15 '18 at 09:54
  • Because open source code is likely better than what someone could code individually @Goyo – Billal Begueradj Oct 15 '18 at 18:08
  • You always can do without – PlasmaHH Oct 15 '18 at 18:20
  • 1
    Voted to close because the question seems to have been re-formulated significantly, and the upper answers answer the old version... better re-post the question as it stands now on its own (plus add the details to avoid the "too board" votes)... – AnoE Oct 15 '18 at 19:15
  • 1
    I had to reformulate it because there were complaints about it (3 votes to close it) @AnoE – Billal Begueradj Oct 16 '18 at 05:03
  • 1
    @AnoE He changed some words and reformulated a sentence, do you really think he should post that as a new question? Answers still seem relevant to me, excellent question. – Alex Oct 20 '18 at 09:41

7 Answers7

55

As an engineer, perhaps it is suitable to think of this as an optimization problem. Naturally we must have an optimization goal. A common one in this sort of situation would be to minimize Total Cost of Ownership.

If you believe adding the third party component will save cost in the long run, you should use it. If you don't, you shouldn't. Make sure you consider the cost of ongoing maintenance (for example, when a new version of O/S is released, or a security flaw is found, or some new W3C specification is released).

For many trivial problems, it will be lower cost to grow your own, but for moderately complex problems outside your organization's core competency, it will often make sense to go third party.

There are other goals to consider too (e.g. risk) but TCO is the big one.

John Wu
  • 26,032
  • 10
  • 63
  • 84
  • 1
    I think this answer needs more upvotes. - The long term reliability with libraries can be a huge problem. And even if a library exists, who knows if the APIs will change? Libraries are easy in the short term, but can cause problems in the long term. (Side note: libraries as source code mitigate some of the problems.) – DetlevCM Oct 15 '18 at 09:11
  • 6
    @DetlevCM The answer is also saying it can very easily go the other way round. Nontrivial libraries will have maintenance costs attached to them that you as a user of the library don't have to pay, and perhaps wouldn't be able to pay if you had to (i.e. if you were the owner of the library). – Cubic Oct 15 '18 at 12:52
  • I agree but don't forget to consider the cost of the library as well--bugs, design changes outside your control, and bunches of code you aren't using just to bring in a single function. Also the library often isn't as expressive as your solution might be for your given problem. ALSO you can't debug an external library as easily and if you do you have to deal with more merge issues later. Don't just assume that a library solution is more light-weight, consider all the factors and don't be afraid to code your own solution if the library doesn't quite fit! – Bill K Oct 15 '18 at 17:46
36

Bill Gates once famously said:

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

This quote comes to mind because the same could ultimately be said for the number of libraries. As a rule, I don't use libraries unless:

  1. There's no other way of getting it done. Doing without would no longer be economically viable to produce the product on time and on budget.
  2. It would save me a significant chunk of time as I would require many of the features of said library
  3. Library is well-used and any potential problems I might have would be well-documented.

Ideally all three conditions are met, but I'd settle for any two. Bottom line is you shouldn't be adding a library to your program unless it serves a purpose. If you have to ask what that purpose is, you probably shouldn't be adding it to your program. The code quality of your program therefore benefits because it elegantly calls upon each library without being weighed down by the need to necessarily rewrite libraries inside your program.

Good luck!

Neil
  • 22,670
  • 45
  • 76
  • `There's no other way of getting it done` quite contradictory, isn't? If there's a library that does it, then there's "a way" to do it. `It would save me a significant chunk of time` this is the only reason. – Laiv Oct 15 '18 at 06:43
  • @Laiv I would invite you to try to write a program in Java without the jdk then. To clarify, I don't mean "impossible". I mean impractical. – Neil Oct 15 '18 at 06:44
  • Edited for clarity. – Neil Oct 15 '18 at 06:50
  • 4
    @BillalBegueradj Meaningful quote, yes. Adequate, no. We are not talking about progress, we are talking about software quality, and lines of code has a very strong correlation to numbers of defects found. See the paper [The Confounding Effect of Class Size on the Validity of Object-Oriented Metrics](https://sci-hub.tw/10.1109/32.935855) which shows all other metrics have no predictive power on found defects after adjusting by LOC, meaning that LOC is the best predictor for defects (or was at the time: 2001). *And, by the way, scientific paper beats famous quote.* – Theraot Oct 15 '18 at 07:17
  • 5
    @Theraot You're suggesting that since the number of lines determines the number of defects that larger programs have worse code quality than smaller programs? I don't agree with your metric, sorry. Also, if the quote really bothers you, feel free to ignore. – Neil Oct 15 '18 at 07:27
  • 3
    @Neil to be clear, number of lines does not determine the number of defects, it has a strong correlation with number of defects found. This is easy to understand: the larger the code, the more opprotunities for defects to be introduced. Of course, the number of defect would go down after they are found and fixed. This is only correlation after all. Addendum: LOC beats many common metrics, see the paper for details. – Theraot Oct 15 '18 at 07:47
  • 5
    @Theraot My argument wasn't with the correlation of defects to number of lines. My argument was with the sheer number of defects equating to bad code quality. Chrome has had its share of defects over the years, but I would argue the legitimacy of any claim which suggests it is written worse than a badly written 10-line jQuery plugin on github. – Neil Oct 15 '18 at 07:53
  • 3
    @Theraot "scientific paper beats famous quote." - it sounds like your paper actually supports the quote rather than beats it... – npostavs Oct 15 '18 at 14:11
  • 1
    IMO the Gates quote is complete nonsense, because for an aircraft *the weight is already known, to high accuracy, at the design stage, before anything has been built*. Given that fact, the "weight of a part-built plane" *is* a measure of how much has been completed, though not a very practical one. – alephzero Oct 15 '18 at 14:27
  • @alephzero so then the quote would still apply, but to the aircraft during the design stage, rather than the actual construction process, no? – swhat Oct 15 '18 at 16:35
  • Did Bill Gates *actually* say that, or did someone just attribute it to him? Lots of references to him saying it, but none mention *where* he said it. (Book? Speech? Interview?) – chepner Oct 15 '18 at 18:57
14

(Note: The original question was: Does the number of libraries improve code quality?)

You can probably answer that one for yourself: No, of course the mere fact of using libraries doesn't improve your code. If it did, it would be easy to write great code for everything with no effort.

What people mean when they recommend reuse over roll-your-own is that code in a well-known library is probably more correct, efficient and/or usable than what you would yourself come up with, simply because the authors have spent much more time on one particular area of functionality than you (with your deadline for the entire project) can afford.

But that's only a trend, not a law. Certainly there can be libraries that aren't as useful to use as roll-your-own would be. Often this happens when the library actually does much more than what you need, and does it in a way that would force you to adapt your own code base to their conventions much more than is reasonable. It looks as if this is exactly what you've found in this instance.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
4

While using the right libraries can save you a lot of work, there is also a lot of hidden cost:

  • Libraries need to be kept up to date. You regularly need to check if they got updates (which might be security-relevant!) and apply them. Each library update might potentially break something in your application. That means you need to perform a complete integration test afterwards. So every library your project depends on increases the long-term maintenance overhead.
  • Some Javascript libraries are so powerful and use such unique patterns that people start to perceive them as separate technical areas of expertise. So each additional library you add might scare away developers who do not feel confident editing code which relies on a framework they are not familiar with. Hiring new maintenance programmers who are familiar with all the libraries you use might become challenging.
  • Adding a library to your website increases loading-times, because the user needs to load the whole library, even if you only use a small part of it. Some popular libraries allow you to download custom builds with only the functionality you need, but even then you will usually still include a lot of code which will never run (or even worse: code which does run, but doesn't do anything useful, because it just prepares data-structures for functionality you don't use).

So before you add another dependency to your project to include something you could just as well write yourself, do a cost/benefit analysis.

Philipp
  • 23,166
  • 6
  • 61
  • 67
  • And repeat that analysis when you really have real data. You might have underestimated the cost / overestimated the benefit, or the situation might have changed. – Deduplicator Oct 15 '18 at 14:30
1

This needn't be a binary decision: Either only use an OSS library, or program a new solution from scratch. Another option may be to re-use parts of the library, if the licence allows it.

For example, in my field (numerical software) a library can have fine core modules, and some specialised modules that I'm only 80% happy with. So I'd use the core modules and write a wrapper for the specialised modules. Or I may develop my own specialised modules by using the design and code of the OSS modules. The hardest, algorithmic bits usually get re-used from those, with only scaffolding code modified. I may also clean up some of the original code. This has proven a good learning experience and a time-saver, compared to development from scratch.

schrödingcöder
  • 823
  • 8
  • 15
0

If someone has done the work for you already, of course you should use it.

The exception to the rule is javascript. Where they will have imported a dozen other libraries (obsolete versions of course) to add the language features they want to use and then done the work for you.

Pick your framework and stay within it. If the library works with your framework or plain js, fine. But if it needs a different framework, look for another option.

Ewan
  • 70,664
  • 5
  • 76
  • 161
0

Libraries and when to use them is a complicated decision.

On the one hand you have well tested, almost standard things (In my field, FFTW for example falls into this category, or something like libsndfile), which are generally acknowledged to just work, and have been standard things for the last 20 years that everyone uses.

On the other hand you have random stuff from github, with no test suite and only about 1 maintainer, generally why bother?

The acid test for me is firstly does the library fit into my architecture (Sometimes, if you know you want to use a given library you end up designing around that), and do I think I am going to wind up debugging someone elses library code? A good proxy for the second question is "Is there an automated test suite and what is the documentation like?".

A little debugging is not a major problem, but at that point the library code starts to count against my own code size from a maintenance perspective (More so if my fixes cannot be pushed to upstream for some reason).

I would also differentiate between libraries and frameworks, for all that the distinction is sometimes not that clear cut, frameworks in my (small core, DSP heavy) world tend to be a pain in the arse, especially if you are trying to merge more then one or do something slightly outside the lines, libraries are sometimes useful. I am aware that this is seen very differently in the web dev scene.

End of the day it is a decision that comes down to taste and experience, and even the experienced sometimes pick poorly, still at least with a library, you can always tear it out and write your own implementation if it gets too annoying.

Decisions, Decisions....

Dan Mills
  • 642
  • 3
  • 8