4 ms·

> Perhaps a library covers only 95% of the requirements 95% isn't "only". That's pretty darn high. I'd wish that in-house code covered 95% of requirements more

by V-2 10y ago

> Perhaps a library covers only 95% of the requirements 95% isn't "only". That's pretty darn high. I'd wish that in-house code covered 95% of requirements more often. If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. > Being available in a package manager, being downloaded by thousand of people, or having a fancy web page, are no indications of a good product. 1. Being used by thousands of people isn't by itself a guarantee that it's good, but it surely makes it more likely. 2. Obviously noone sane would pick third party libraries based on how fancy some web page is. That's a strawman argument.

wolfgke 10y ago
> If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. Depending on the situation this can mean having to understand lots of gory details of the implementation of the library. It is often easier to write an own implementation from scratch than having to understand these details and subtile interactions. Typically "open source" just means that the source code is available under an OSI-compatible license and not that there is also a documentation available that guides you from barely understanding the library to understanding every implementation details that is necessary to do internal changes.
wtbob 10y ago
> If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. You're not wrong, but you are assuming some things: 1. That the library is written in a language suitable for the task. E.g. if you're doing real-time programming you probably don't want Visual Basic and if you're doing security programming or text processing you probably don't want C. 2. That the library is written well enough to read. You'd be amazed how much truly bad code is out there. It runs, but … it's not good. OpenSSL is an example. 3. That the library is architected in such a fashion that the 5% functionality can be added without major rework. The functionality may be small, but adding it might require quite a lot of architectural change and refactoring.
- V-2 10y ago
  There can always be exceptions, I agree. And these are much better points that in the commented article, imho. Anyhow, we're talking averages here - the default mindset, if you will.
imagist 10y ago
> 95% isn't "only". That's pretty darn high. I'd wish that in-house code covered 95% of requirements more often. > If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. The percentage isn't relevant if working around the design of the library to fulfill the missing 5% takes 30x as long as just writing the code yourself. Additionally, libraries often do a lot of things you don't need, so you get a bunch of bloat along with the stuff you want. > Obviously noone sane would pick third party libraries based on how fancy some web page is. That's a strawman argument. We can argue about the sanity of people, but the fact remains that people on teams I've worked on have chosen libraries based on the fanciness of their webpage.
- V-2 10y ago
  > The percentage isn't relevant if working around the design of the library to fulfill the missing 5% takes 30x as long as just writing the code yourself. Of course, but one should be aware of a tendency to overestimate the effort required for tweaking third party code (understanding somebody else's code is always more difficult), and underestimate the effort required for writing the thing from scratch. It's closely related to the infamous "Big Rewrite" problem. > the fact remains that people on teams I've worked on have chosen libraries based on the fanciness of their webpage I believe you, but I find it difficult to believe these would be the same people who tend to introspect on their profession a lot, eg. by following software engineering blogs, so the author is kind of preaching to the choir in my view.
  - imagist 10y ago
    > Of course, but one should be aware of a tendency to overestimate the effort required for tweaking third party code (understanding somebody else's code is always more difficult), and underestimate the effort required for writing the thing from scratch. It's not just the cost of tweaking, it's the cost of keeping it up-to-date, too. I agree with the general gist of what you're saying, just wanted to point out there's more to it. > I believe you, but I find it difficult to believe these would be the same people who tend to introspect on their profession a lot, eg. by following software engineering blogs, so the author is kind of preaching to the choir in my view. On the contrary, I think people who don't introspect about what they're doing are more likely to read tech blogs. How else would they find out what the latest fad libraries are so they can treat them as best practices? :)

by V-2 10y ago

wolfgke 10y ago

> If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. Depending on the situation this can mean having to understand lots of gory details of the implementation of the library. It is often easier to write an own implementation from scratch than having to understand these details and subtile interactions. Typically "open source" just means that the source code is available under an OSI-compatible license and not that there is also a documentation available that guides you from barely understanding the library to understanding every implementation details that is necessary to do internal changes.

wtbob 10y ago

> If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. You're not wrong, but you are assuming some things: 1. That the library is written in a language suitable for the task. E.g. if you're doing real-time programming you probably don't want Visual Basic and if you're doing security programming or text processing you probably don't want C. 2. That the library is written well enough to read. You'd be amazed how much truly bad code is out there. It runs, but … it's not good. OpenSSL is an example. 3. That the library is architected in such a fashion that the 5% functionality can be added without major rework. The functionality may be small, but adding it might require quite a lot of architectural change and refactoring.

V-2 10y ago
There can always be exceptions, I agree. And these are much better points that in the commented article, imho. Anyhow, we're talking averages here - the default mindset, if you will.

imagist 10y ago

> 95% isn't "only". That's pretty darn high. I'd wish that in-house code covered 95% of requirements more often. > If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. The percentage isn't relevant if working around the design of the library to fulfill the missing 5% takes 30x as long as just writing the code yourself. Additionally, libraries often do a lot of things you don't need, so you get a bunch of bloat along with the stuff you want. > Obviously noone sane would pick third party libraries based on how fancy some web page is. That's a strawman argument. We can argue about the sanity of people, but the fact remains that people on teams I've worked on have chosen libraries based on the fanciness of their webpage.

V-2 10y ago
> The percentage isn't relevant if working around the design of the library to fulfill the missing 5% takes 30x as long as just writing the code yourself. Of course, but one should be aware of a tendency to overestimate the effort required for tweaking third party code (understanding somebody else's code is always more difficult), and underestimate the effort required for writing the thing from scratch. It's closely related to the infamous "Big Rewrite" problem. > the fact remains that people on teams I've worked on have chosen libraries based on the fanciness of their webpage I believe you, but I find it difficult to believe these would be the same people who tend to introspect on their profession a lot, eg. by following software engineering blogs, so the author is kind of preaching to the choir in my view.
- imagist 10y ago
  > Of course, but one should be aware of a tendency to overestimate the effort required for tweaking third party code (understanding somebody else's code is always more difficult), and underestimate the effort required for writing the thing from scratch. It's not just the cost of tweaking, it's the cost of keeping it up-to-date, too. I agree with the general gist of what you're saying, just wanted to point out there's more to it. > I believe you, but I find it difficult to believe these would be the same people who tend to introspect on their profession a lot, eg. by following software engineering blogs, so the author is kind of preaching to the choir in my view. On the contrary, I think people who don't introspect about what they're doing are more likely to read tech blogs. How else would they find out what the latest fad libraries are so they can treat them as best practices? :)