5 ms·

"Not Invented Here" Versus Developer Sanity

49 points by pmarin 14y ago

russell_h 14y ago
I don't disagree with the OP* but its important to recognize that what might seem to keep you sane, in many situations it will drive whoever inherits your code absolutely nuts. The guidelines the article lays out aren't bad, but they are all about "you". Make sure you don't forget the next person. *I'm well known among my colleagues for writing way too much from scratch
- cdooh 14y ago
  I think his main concern was for the users or did I read it wrong?
- readme 14y ago
  It really depends on how good you are at writing readable, unsurprising, code, and how willing you are to document it.
deleted 14y ago
[deleted]
cdooh 14y ago
I think he's right, but this is really a problem a developer would have. Most users just want the very best exprience, which in most cases means the most upgraded software. If you can build the tool for yourself though do it.
camus 14y ago
Fair point. I like the article about OOP too : http://prog21.dadgum.com/156.html http://prog21.dadgum.com/156.html
azylman 14y ago
At work recently we reinvented something that already existed - but I think we had a good reason to. There's a node package called "request" [1] that's a very, very popular third-party library to simplify HTTP requests. If you look at the code, though, it's really, really nasty - the whole thing is filled with global state. After I spent 6 hours in one day debugging issues in the library and filing bugs (some of which included things such as "if you try to set a querystring parameter, request can no longer follow redirects"), we decided that enough was enough and we rewrote it from scratch [2]. I think that rewriting it took us about as much time as we spent debugging it, but we were left with a project that's a drop-in replacement (as long as you're not using any of the advanced features) and has a codebase that's 1/10th (!!!) as many lines of code while implementing near 80% of its features. [1] https://github.com/mikeal/request https://github.com/mikeal/request [2] https://github.com/clever/quest https://github.com/clever/quest
- aaronbrethorst 14y ago
  Perhaps the other 9/10ths of the code implement the other 20% of the features?* * Half joking.
  - azylman 14y ago
    I think roughly 40% of the remaining code implements the last 20% of the features, and the other 50% is just random bloat. Request has a lot of extra code to deal with the global state. It's written as one giant class that sets all of its properties on itself (e.g. this.method = options.method, etc., etc., followed by "http.request this"). Further, when it handles HTTP redirects, rather than instantiate a new instance of itself or something it just calls its init method a second time and has to make sure that it resets all of its properties to their default state (e.g. this.method = 'GET'). This is where most of the bugs come in, as well as most of the bloat. In contrast, our's is a method that calls itself again with new options based on the context when it needs to handle HTTP redirects so we don't need to worry about that sort of stuff.
- rlpb 14y ago
  I don't think NIH counts as NIH when you have a very clear and justifiable rationale. The best projects document their rationale and provide a direct, unbiased comparison to allow developers to make a better decision on which to use, as you have. The worst (and true NIH) projects pretend that the original project does not exist or document a biased comparison without acknowledging the points that are subjective. There is one improvement I'd make. Your story here (spent hours debugging and filing bugs; spending the same amount of time rewriting got you further) is the most convincing reason to me. I'd document this in your comparison!
  - mdpye 14y ago
    Exactly; NIH syndrome refers to the fact that it wasn't invented in house /being/ (or tainting) the rational. Edit: replace failed attempt at italics...
    - 14y ago
userulluipeste 14y ago
Most of the implementing in software is not conducted as engineering, it's conducted more like research. "Reinventing the wheel" actually means a (potentially better) retake on the same problem. It means the fact of questioning the existing things which is never bad, it only gives the chance of changing them with new better ones or just to validate their existing value.

49 points by pmarin 14y ago

I don't disagree with the OP* but its important to recognize that what might seem to keep you sane, in many situations it will drive whoever inherits your code absolutely nuts. The guidelines the article lays out aren't bad, but they are all about "you". Make sure you don't forget the next person. *I'm well known among my colleagues for writing way too much from scratch

cdooh 14y ago
I think his main concern was for the users or did I read it wrong?
readme 14y ago
It really depends on how good you are at writing readable, unsurprising, code, and how willing you are to document it.

deleted 14y ago

[deleted]

cdooh 14y ago

I think he's right, but this is really a problem a developer would have. Most users just want the very best exprience, which in most cases means the most upgraded software. If you can build the tool for yourself though do it.

camus 14y ago

Fair point. I like the article about OOP too : http://prog21.dadgum.com/156.html http://prog21.dadgum.com/156.html

azylman 14y ago

At work recently we reinvented something that already existed - but I think we had a good reason to. There's a node package called "request" [1] that's a very, very popular third-party library to simplify HTTP requests. If you look at the code, though, it's really, really nasty - the whole thing is filled with global state. After I spent 6 hours in one day debugging issues in the library and filing bugs (some of which included things such as "if you try to set a querystring parameter, request can no longer follow redirects"), we decided that enough was enough and we rewrote it from scratch [2]. I think that rewriting it took us about as much time as we spent debugging it, but we were left with a project that's a drop-in replacement (as long as you're not using any of the advanced features) and has a codebase that's 1/10th (!!!) as many lines of code while implementing near 80% of its features. [1] https://github.com/mikeal/request https://github.com/mikeal/request [2] https://github.com/clever/quest https://github.com/clever/quest

aaronbrethorst 14y ago
Perhaps the other 9/10ths of the code implement the other 20% of the features?* * Half joking.
- azylman 14y ago
  I think roughly 40% of the remaining code implements the last 20% of the features, and the other 50% is just random bloat. Request has a lot of extra code to deal with the global state. It's written as one giant class that sets all of its properties on itself (e.g. this.method = options.method, etc., etc., followed by "http.request this"). Further, when it handles HTTP redirects, rather than instantiate a new instance of itself or something it just calls its init method a second time and has to make sure that it resets all of its properties to their default state (e.g. this.method = 'GET'). This is where most of the bugs come in, as well as most of the bloat. In contrast, our's is a method that calls itself again with new options based on the context when it needs to handle HTTP redirects so we don't need to worry about that sort of stuff.
rlpb 14y ago
I don't think NIH counts as NIH when you have a very clear and justifiable rationale. The best projects document their rationale and provide a direct, unbiased comparison to allow developers to make a better decision on which to use, as you have. The worst (and true NIH) projects pretend that the original project does not exist or document a biased comparison without acknowledging the points that are subjective. There is one improvement I'd make. Your story here (spent hours debugging and filing bugs; spending the same amount of time rewriting got you further) is the most convincing reason to me. I'd document this in your comparison!
- mdpye 14y ago
  Exactly; NIH syndrome refers to the fact that it wasn't invented in house /being/ (or tainting) the rational. Edit: replace failed attempt at italics...
  - 14y ago

userulluipeste 14y ago

Most of the implementing in software is not conducted as engineering, it's conducted more like research. "Reinventing the wheel" actually means a (potentially better) retake on the same problem. It means the fact of questioning the existing things which is never bad, it only gives the chance of changing them with new better ones or just to validate their existing value.