
"Not Invented Here" Versus Developer Sanity - pmarin
http://prog21.dadgum.com/158.html
======
azylman
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>

[2] <https://github.com/clever/quest>

~~~
rlpb
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
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...

~~~
saurik
I doubt that many people say with a straight face "I rebuilt it because I
didn't write the original", even if that's the _real_ reason: there is always
an excuse.

------
russell_h
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

~~~
readme
It really depends on how good you are at writing readable, unsurprising, code,
and how willing you are to document it.

------
userulluipeste
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.

------
cdooh
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
Fair point. I like the article about OOP too :

<http://prog21.dadgum.com/156.html>

