"Not Invented Here" Versus Developer Sanity | Hacker News Reader

"Not Invented Here" Versus Developer Sanity

prog21.dadgum.com

49 pointspmarin12 comments

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

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!

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

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.

Perhaps the other 9/10ths of the code implement the other 20% of the features?*

* Half joking.

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.

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

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

I think his main concern was for the users or did I read it wrong?

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.

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.

Fair point. I like the article about OOP too :

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

Reply on news.ycombinator.com