No, not "NIH" as in "National Institute of Health," actually. What I'm talking about is the "Not Invented Here" syndrome, first (for me, anyway) outlined in a Joel On Software blog post. (No relation to the web comic of the same name. At least, not as far as I know...)
The twist on the idea that occurred to me today was: It's not even a question of trusting the borrowed/purchased code when your marching orders consist of:
1.) Copy.
2.) Paste.
3.) Edit.
4.) Profit!
Rather, it's a question of what I call "borrowed expectations." Because Step #4--in my experience, anyway--is entirely predicated on the assumption, "It shouldn't take you that long." Or at least, "This should be a no-brainer." As a programmer, either of those phrases should set off the equivalent of Yellow Alert in your brain. I hesitate to put any hard numbers to it, but, after the last week, my gut's version of Algebra suggests taking your default "sandbag factor" and applying it every time you hear one of the above phrases (or a variation thereof).
In other words, if you usually sandbag by 25%--i.e. have a sandbag factor of 1.25--then you take your original time estimate and multiply it by 1.25 every single time someone informs you that "...all you need to do is..." or "...So-and-so's already done 99% of the work for you..." or "...all you and QA need to worry about is..."
All such key-phrases? Horse-hockey.
All of them.
Why? Because of a simple logical inference that should be--but mostly isn't--burned into any programmer's synapses from the get-go: Legacy Code => Constraints. In purely Algebraic terms, the correlation between the two is linear--if you're lucky. To wit: Remember how they taught you in Health Class that when you sleep with a person, you're sleeping with all their former partners and the partners of those partners all the way back to Adam and Eve? Yeah. Well, include-files (and the implicit--and often unfathomable--design decisions they implement) are basically All That And a Bag of Chips(TM @garyvee), too. Except that, with code, abstinence isn't an option: 'Nuff said.
Now, I'm not saying that there isn't a time and a place for code re-use. Actually, make that "times" and "places." I'm merely decrying the eternal optimism that such reuse embodies--even in people whose experience should be telling them--at mega-decibel volumes--that the statistical liklihood of it being "just that simple" is on par with lightning strikes, shark attacks, penny-stock billionaires and the like. Thus, arm yourself accordingly. With sandbagging, documentation (of every--cough--"unforeseen" complication), the appropriate "I told you so"s and so forth.
Look. I adore the office Alpha-Geek, and would trust him (and the majority of my co-workers) with my cat, houseplants, etc. But there are limits, and the afore-mentioned borrowed expectations of already-written-and-tested code numbers among them. There's just something about that that confounds even the left-most of left-brainers. And it's best that aspiring programmers (as well as those who work with them) recognize that. And react accordingly. And, whenever possible, don't wait to merely react; bake it into Standard Operating Prodedure.
