3 ms·

> 1. The proliferation of libraries enables devs to get very, very picky about their libraries - the slightest wart or lack of understanding will cause them to

by imagist 10y ago

> 1. The proliferation of libraries enables devs to get very, very picky about their libraries - the slightest wart or lack of understanding will cause them to label a library "utterly crap". But anything they create to replace it will run afoul of another programmer's picky tastes even worse! (And to what degree they may have a point, exactly 0 devs will be previously familiar with the warts and misfeatures of this new code.) Ah yes, the "it's all subjective" argument. The thing is, it's not subjective. Sure, it may be hard to objectively measure the qualities of a library, but that doesn't mean we should give up and assume there's no underlying objective truth. My "picky tastes" are for libraries that are battle-tested, performant, and scalable. If that runs afoul of someone else's tastes, frankly, I don't care. > 2. As I get better at project management, I realize that myself and my fellow devs are constantly underestimating the ongoing maintenance burdens of new code. It's hard enough getting us to make sufficiently pessimistic time estimates for the initial implementation that PMs don't have to smile and multiply by large integers - nevermind accounting for the next few years of adding additional debug logic, logging, fixing edge cases, supporting legacy decisions, adding a full set of fuzzing and regression tests, etc. I definitely agree that the ongoing maintenance burden of new code is consistently underestimated, but it doesn't follow from that that we should prefer third-party libraries to our own code. A new third party library is still new code, and it's not often a reliable assumption that someone else will maintain that code forever. Further, general-purpose third party libraries aren't tailored to our needs, so they often contain more code than we would write. The result? We often end up with a larger maintenance burden by using a library. And finally, even if someone else maintains your library, that doesn't mean they will maintain the integration point between your code and theirs. Keeping up with changes in a library that doesn't value reverse compatibility highly can be just as costly as maintaining a library yourself.

crpatino 10y ago
> ... but it doesn't follow from that that we should prefer third-party libraries to our own code. Agreed. The big tragedy of Open Source is that after its initial wave of success it good flooded with freeloaders. If you allow me to repeat myself: The one flaw of the GPL is that it did not offer provisions to prohibit distribution in binary form. "You want free? Better you know how to unpack the tarball and build the project from scratch... all by yourself (No build scripts beyond Makefile permitted, thank you very much)". Of course, such overzealous GPL would need to also make provisions to accept dual licensing with nice, commercial, royalty seeking licences. That way, everybody gets what they value the most: You want freedom, you pay with sweat; you just want access, you pay in cash.
- imagist 10y ago
  That would pretty much defeat the entire goal of free software. Setting up a technical barrier to usage is counter to free software goals.
  - crpatino 10y ago
    And what are those goals? Provide free labor to corporate interests? Give away free products to cheap people that cannot care to recognize for one second the personal effort invested by the producers? Creators are going to create, they cannot help it. I do not say that you cannot provide altruistic value to others, but my opinion is that you should care about your own people first. And the big mistake of programmers as a profession is that we do not see other fellow programmers as our own people.
MaulingMonkey 10y ago
> Ah yes, the "it's all subjective" argument. The thing is, it's not subjective. Some things are, some things aren't - and even some of the subjective objections can be reasonable. If your entire dev team is a bunch of crusty C programmers with no exception handling experience, introducing a new library that throws exceptions has drawbacks, no matter how reasonably they might be used. They're simply not in the right mindset for it. If it's just 1 member of your dev team, however, perhaps it's time for them to learn to deal with exception handling if the library is otherwise good. Then I see devs getting very passionate about vanilla XML vs JSON, CamelCase vs snake_case, and making kneejerk reactions to well documented edge cases that their replacement implementations would also have (minus the documentation.) Your tastes are a bit better, but even there I can think of scenarios where all three aren't vital to me - easily fungible dev-only debug tools come to mind. > Sure, it may be hard to objectively measure the qualities of a library, but that doesn't mean we should give up and assume there's no underlying objective truth. Agreed. But I find that the best way to measure is to have at least one person try - or have previous experience with - using the library. Obscenely convoluted dependency chains that can't be simply checked into VCS? Consistently unstable? Insecure by design and defaults? Constant public interface churn? I agree that there are reasons to kill a library with fire - sometimes before you decide to integrate it in the first place, sometimes after the fact when you've realized it was a mistake. > The result? We often end up with a larger maintenance burden by using a library. I see this rather rarely, which does make me think we've spent time on opposite ends of the NIH spectrum. It does happen though, and those are libraries that I will still avoid.

by imagist 10y ago

crpatino 10y ago

> ... but it doesn't follow from that that we should prefer third-party libraries to our own code. Agreed. The big tragedy of Open Source is that after its initial wave of success it good flooded with freeloaders. If you allow me to repeat myself: The one flaw of the GPL is that it did not offer provisions to prohibit distribution in binary form. "You want free? Better you know how to unpack the tarball and build the project from scratch... all by yourself (No build scripts beyond Makefile permitted, thank you very much)". Of course, such overzealous GPL would need to also make provisions to accept dual licensing with nice, commercial, royalty seeking licences. That way, everybody gets what they value the most: You want freedom, you pay with sweat; you just want access, you pay in cash.

imagist 10y ago
That would pretty much defeat the entire goal of free software. Setting up a technical barrier to usage is counter to free software goals.
- crpatino 10y ago
  And what are those goals? Provide free labor to corporate interests? Give away free products to cheap people that cannot care to recognize for one second the personal effort invested by the producers? Creators are going to create, they cannot help it. I do not say that you cannot provide altruistic value to others, but my opinion is that you should care about your own people first. And the big mistake of programmers as a profession is that we do not see other fellow programmers as our own people.

MaulingMonkey 10y ago

> Ah yes, the "it's all subjective" argument. The thing is, it's not subjective. Some things are, some things aren't - and even some of the subjective objections can be reasonable. If your entire dev team is a bunch of crusty C programmers with no exception handling experience, introducing a new library that throws exceptions has drawbacks, no matter how reasonably they might be used. They're simply not in the right mindset for it. If it's just 1 member of your dev team, however, perhaps it's time for them to learn to deal with exception handling if the library is otherwise good. Then I see devs getting very passionate about vanilla XML vs JSON, CamelCase vs snake_case, and making kneejerk reactions to well documented edge cases that their replacement implementations would also have (minus the documentation.) Your tastes are a bit better, but even there I can think of scenarios where all three aren't vital to me - easily fungible dev-only debug tools come to mind. > Sure, it may be hard to objectively measure the qualities of a library, but that doesn't mean we should give up and assume there's no underlying objective truth. Agreed. But I find that the best way to measure is to have at least one person try - or have previous experience with - using the library. Obscenely convoluted dependency chains that can't be simply checked into VCS? Consistently unstable? Insecure by design and defaults? Constant public interface churn? I agree that there are reasons to kill a library with fire - sometimes before you decide to integrate it in the first place, sometimes after the fact when you've realized it was a mistake. > The result? We often end up with a larger maintenance burden by using a library. I see this rather rarely, which does make me think we've spent time on opposite ends of the NIH spectrum. It does happen though, and those are libraries that I will still avoid.