4 ms·
It's a matter of balance, always. A thin line. And dogmas that people on teams follow (we all do in some way). Not invented here syndrome, always create a clas
by juangacovas 7y ago
It's a matter of balance, always. A thin line. And dogmas that people on teams follow (we all do in some way).
Not invented here syndrome, always create a class, always put a class in its own file, premature optimization blablah, don't use goto, this and that is bad practice in that language, don't optimize until you need it (but you later don't have time to profile, or don't really want to...)
- majewsky 7y agoNever-invent-here syndrome is just as bad as not-invented-here syndrome, though.
- armitron 7y agoNo, never-invent-here (aka extensive 3rd party library reuse) is orders of magnitude worse. NIH means you retain full control of your codebase. It's really determinism that leads to you being able to make reliability/robustness, availability and security guarantees. Never-invent-here is a disaster waiting to happen.
- lonelappde 7y agoExternal code is better than internal code because you can reduce it to internal code just by forking it. If it is even minkscully useful, that's a win.