3 ms·

> 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

by 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? :)
  - pkolaczk 10y ago
    I agree that understanding someone else's code is typically easier than writing that code from scratch. But that's just part of the equation. Another part is how much of that code you have to understand / write. Understanding 1 MLOC framework with all its quirks may be much harder than writing 1 thousand lines of code implementing a feature that you want. So if you need only 5% of functionality of a huge general-purpose library, it may be still actually faster to write that 5% functionality by yourself, than to understand, tweak and later maintain the library.
    - imagist 10y ago
      I think we're agreeing. :)

by imagist 10y ago

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? :)
- pkolaczk 10y ago
  I agree that understanding someone else's code is typically easier than writing that code from scratch. But that's just part of the equation. Another part is how much of that code you have to understand / write. Understanding 1 MLOC framework with all its quirks may be much harder than writing 1 thousand lines of code implementing a feature that you want. So if you need only 5% of functionality of a huge general-purpose library, it may be still actually faster to write that 5% functionality by yourself, than to understand, tweak and later maintain the library.
  - imagist 10y ago
    I think we're agreeing. :)