4 ms·

On the other hand I have seen many functions that were written in 10 minutes that are utterly broken except for the most common cases. Where a library function

On the other hand I have seen many functions that were written in 10 minutes that are utterly broken except for the most common cases. Where a library function should have been used because the programmer did not understand the depth of the problem.

yoklov 11y ago
It's easier to fix those than extract a dependency or remove bloat.
- MaulingMonkey 11y ago
  Not when those ten minute functions add up and become a bloated dependency it isn't.
  - enraged_camel 11y ago
    Yep, exactly. 80% of a feature may take 20% of the time to develop, but the rest (edge cases) will take the majority of the time, and that's time you could have spent working on core features for your system. That's why it's almost always better to use an existing library: chances are most of the bugs will already have been encountered and squashed. I find the whole "do it yourself" mentality to be a form of NIH syndrome.
    - Too 11y ago
      I often found that your remaining 20% is not the same 20% as the library authors, unless the task at hand is very constrained and standardized. Everybody has different edge cases. Finding the bugs relevant to your application in someone elses code is much harder than finding it in your own.
      - MaulingMonkey 11y ago
        My code turns into "someone elses" code after a mere few years, and my coworkers code is already by definition "someone elses" code, in my experience. Replacing "our" code with a pre-existing library has been a great way to flush out bugs both in our replaced code, and in our calling code, as well.
BurningFrog 11y ago
Yeah, being able to distinguish these cases is an important skill. One case I learned the hard way (once!) is parsing/writing CSV files. It seems so simple. But there are 3-5 special cases that are hard and rare enough that you always should use the standard library written for your language. Perhaps admitting your original decision didn't work out and and starting over is the real important skill...
- userbinator 11y ago
  Parsing standard CSV isn't that hard (I've written one) when you have a spec to follow: https://tools.ietf.org/html/rfc4180 https://tools.ietf.org/html/rfc4180 But in my experience, a lot of generated CSV is non-standard, and in that case finding a library to do it doesn't help --- you need to write your own parser so you can adapt it to the quirks of the variant(s) you're consuming.
  - wnoise 11y ago
    Although cleaning filters and a standard parser works well too.
- Chris2048 11y ago
  Hmm, I'm not sure I like this. It would ultimately be an assessment of your own ignorance of a subject. Maybe coding based on researching solutions is a good way to do things - we just need to make it more efficient. Looking for an existing implementation, when a "10m implementation will do" - How do you know it will do if you've not researched more? When do you stop? I think risk-assessment should be more of a thing in software development. We can't really know where the bugs might be, but we can know where we'd like them the least?

yoklov 11y ago

It's easier to fix those than extract a dependency or remove bloat.

MaulingMonkey 11y ago
Not when those ten minute functions add up and become a bloated dependency it isn't.
- enraged_camel 11y ago
  Yep, exactly. 80% of a feature may take 20% of the time to develop, but the rest (edge cases) will take the majority of the time, and that's time you could have spent working on core features for your system. That's why it's almost always better to use an existing library: chances are most of the bugs will already have been encountered and squashed. I find the whole "do it yourself" mentality to be a form of NIH syndrome.
  - Too 11y ago
    I often found that your remaining 20% is not the same 20% as the library authors, unless the task at hand is very constrained and standardized. Everybody has different edge cases. Finding the bugs relevant to your application in someone elses code is much harder than finding it in your own.
    - MaulingMonkey 11y ago
      My code turns into "someone elses" code after a mere few years, and my coworkers code is already by definition "someone elses" code, in my experience. Replacing "our" code with a pre-existing library has been a great way to flush out bugs both in our replaced code, and in our calling code, as well.

BurningFrog 11y ago

Yeah, being able to distinguish these cases is an important skill. One case I learned the hard way (once!) is parsing/writing CSV files. It seems so simple. But there are 3-5 special cases that are hard and rare enough that you always should use the standard library written for your language. Perhaps admitting your original decision didn't work out and and starting over is the real important skill...

userbinator 11y ago
Parsing standard CSV isn't that hard (I've written one) when you have a spec to follow: https://tools.ietf.org/html/rfc4180 https://tools.ietf.org/html/rfc4180 But in my experience, a lot of generated CSV is non-standard, and in that case finding a library to do it doesn't help --- you need to write your own parser so you can adapt it to the quirks of the variant(s) you're consuming.
- wnoise 11y ago
  Although cleaning filters and a standard parser works well too.
Chris2048 11y ago
Hmm, I'm not sure I like this. It would ultimately be an assessment of your own ignorance of a subject. Maybe coding based on researching solutions is a good way to do things - we just need to make it more efficient. Looking for an existing implementation, when a "10m implementation will do" - How do you know it will do if you've not researched more? When do you stop? I think risk-assessment should be more of a thing in software development. We can't really know where the bugs might be, but we can know where we'd like them the least?