5 ms·

The longer I work, the more NIH I get. There are two reasons for this: 1. The ease of creating a library these days is resulting in a proliferation of utterly

by imagist 10y ago

The longer I work, the more NIH I get. There are two reasons for this: 1. The ease of creating a library these days is resulting in a proliferation of utterly crap libraries, so bringing on a new library is more and more of a liability, both to future reusability of code and to security. 2. As I get better at programming, I more and more often realize that I can write a better version of the library, or just one that better fits my needs. These combine to create a situation where I'm less and less likely to want to import something.

mortoray 10y ago
#1 has a big influence on my argument. I think it was Python and NodeJS library systems that made it super simple for people to publish libraries. There are a lot of trivial libraries out there, and many of questionable quality. Sometimes using a library ends up as more work than writing the bits of code myself. It's not like I'm going to decide to write a new 20k line library for my project, but if something is only a few hundred lines of code it's definitely easier to just rewrite.
onion2k 10y ago
"As I get better at programming, I more and more often realize that I can write a better version of the library, or just one that better fits my needs." That's a good sign. As you get better and more experienced as developer you start to realise the benefit of thinking things through before launching in to writing code or reaching for an existing library. Some times you want to do the first, and other times you want to do the second. There isn't a straightforward "one size fits all" rule to say which approach is best.
awinder 10y ago
#2 I feel like is the trap. As beings with limited amounts of time on this planet, the test should not be about absolutes, but if what we would build is better given the time we would have to devote. And this isn't that strange of a phenomena when you think about it. Construction workers choose hammers rather than forging them on their own, we buy food from supermarkets instead of growing it on our own, etc. One of the principle elements of humanity is our ability to stand on their shoulders of giants, which shouldn't be lost
- imagist 10y ago
  > #2 I feel like is the trap. As beings with limited amounts of time on this planet, the test should not be about absolutes, but if what we would build is better given the time we would have to devote. I don't think it's really about the time you have to devote. Integrating a library can take longer than writing the code yourself, and that doesn't change with respect to the time you have. > And this isn't that strange of a phenomena when you think about it. Construction workers choose hammers rather than forging them on their own, we buy food from supermarkets instead of growing it on our own, etc. One of the principle elements of humanity is our ability to stand on their shoulders of giants, which shouldn't be lost This fact isn't lost on me. My point is that there are actually relatively few giants who have solved an average arbitrarily-chosen problem, and even fewer who have shared their work. If you have 10+ years of programming experience, it shouldn't be hard to find an area where you are the giant.
  - phaedrus 10y ago
    This is not just a defense of NIH but also a good rule of thumb for how to do NIH "right". The more narrowly you define the problem the more likely that the DIY approach will be better in both time and quality.
- phaedrus 10y ago
  There's a high end pizza place in my city. They buy their flour, but they grow their own arugula. They didn't build their own building from scratch, but they did build their own brick ovens from scratch.
MaulingMonkey 10y ago
I'm the opposite. 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.) 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 wonder if we're regressing toward the same mean, or away from it...
- 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.
phaedrus 10y ago
I find myself trending the same way, but for another reason. I've gone back and forth on my viewpoint over my programming career, and now whenever I decide to revisit an old project, I find the "more NIH" I wrote it the more likely it is that I can load it up in a current version of the compiler / IDE and hit "Build and Run" and it will Just Work. Even if I included the external library in the repository, the library still contains extra code I don't need which may fail to build.
jandrese 10y ago
This is something I've come to appreciate over the years as well. The more libraries a project has the harder is it to maintain, despite the libraries supposedly being used to ease maintenance. This goes triple if the libraries in question are commercial closed source things. One company decides to stop supporting that product or the company goes under or gets bought out and suddenly your project is anchored to something that may or may not stay working as the OS changes underneath it. Every library provides a benefit especially on the front end with reducing development time, but also brings liabilities. So you need to strike a balance between getting enough utility out of it and not loading your project down with so many liabilities that it will be impossible to maintain or port. The maintenance overhead of keeping your own code working is usually far less than the maintenance overhead of chasing API changes in the libraries or discovering new bugs that crop up in minor version updates. Even if you go and pull the libraries directly into your project (so you're fixed on specific versions), you still have problems with having a far more complicated build process that fails far more often thanks to problems with the library builds. Or worse, you have version conflicts with installed libraries. In sort: Keep your list of dependencies as short as possible, but no shorter.

by imagist 10y ago

mortoray 10y ago

#1 has a big influence on my argument. I think it was Python and NodeJS library systems that made it super simple for people to publish libraries. There are a lot of trivial libraries out there, and many of questionable quality. Sometimes using a library ends up as more work than writing the bits of code myself. It's not like I'm going to decide to write a new 20k line library for my project, but if something is only a few hundred lines of code it's definitely easier to just rewrite.

onion2k 10y ago

"As I get better at programming, I more and more often realize that I can write a better version of the library, or just one that better fits my needs." That's a good sign. As you get better and more experienced as developer you start to realise the benefit of thinking things through before launching in to writing code or reaching for an existing library. Some times you want to do the first, and other times you want to do the second. There isn't a straightforward "one size fits all" rule to say which approach is best.

awinder 10y ago

#2 I feel like is the trap. As beings with limited amounts of time on this planet, the test should not be about absolutes, but if what we would build is better given the time we would have to devote. And this isn't that strange of a phenomena when you think about it. Construction workers choose hammers rather than forging them on their own, we buy food from supermarkets instead of growing it on our own, etc. One of the principle elements of humanity is our ability to stand on their shoulders of giants, which shouldn't be lost

imagist 10y ago
> #2 I feel like is the trap. As beings with limited amounts of time on this planet, the test should not be about absolutes, but if what we would build is better given the time we would have to devote. I don't think it's really about the time you have to devote. Integrating a library can take longer than writing the code yourself, and that doesn't change with respect to the time you have. > And this isn't that strange of a phenomena when you think about it. Construction workers choose hammers rather than forging them on their own, we buy food from supermarkets instead of growing it on our own, etc. One of the principle elements of humanity is our ability to stand on their shoulders of giants, which shouldn't be lost This fact isn't lost on me. My point is that there are actually relatively few giants who have solved an average arbitrarily-chosen problem, and even fewer who have shared their work. If you have 10+ years of programming experience, it shouldn't be hard to find an area where you are the giant.
- phaedrus 10y ago
  This is not just a defense of NIH but also a good rule of thumb for how to do NIH "right". The more narrowly you define the problem the more likely that the DIY approach will be better in both time and quality.
phaedrus 10y ago
There's a high end pizza place in my city. They buy their flour, but they grow their own arugula. They didn't build their own building from scratch, but they did build their own brick ovens from scratch.

MaulingMonkey 10y ago

I'm the opposite. 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.) 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 wonder if we're regressing toward the same mean, or away from it...

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.

phaedrus 10y ago

I find myself trending the same way, but for another reason. I've gone back and forth on my viewpoint over my programming career, and now whenever I decide to revisit an old project, I find the "more NIH" I wrote it the more likely it is that I can load it up in a current version of the compiler / IDE and hit "Build and Run" and it will Just Work. Even if I included the external library in the repository, the library still contains extra code I don't need which may fail to build.

jandrese 10y ago

This is something I've come to appreciate over the years as well. The more libraries a project has the harder is it to maintain, despite the libraries supposedly being used to ease maintenance. This goes triple if the libraries in question are commercial closed source things. One company decides to stop supporting that product or the company goes under or gets bought out and suddenly your project is anchored to something that may or may not stay working as the OS changes underneath it. Every library provides a benefit especially on the front end with reducing development time, but also brings liabilities. So you need to strike a balance between getting enough utility out of it and not loading your project down with so many liabilities that it will be impossible to maintain or port. The maintenance overhead of keeping your own code working is usually far less than the maintenance overhead of chasing API changes in the libraries or discovering new bugs that crop up in minor version updates. Even if you go and pull the libraries directly into your project (so you're fixed on specific versions), you still have problems with having a far more complicated build process that fails far more often thanks to problems with the library builds. Or worse, you have version conflicts with installed libraries. In sort: Keep your list of dependencies as short as possible, but no shorter.