I'd extend "afternoon" to "half a week", but in general I agree with OP. > Yes, I can write a hashtable implementation in an afternoon, but it's going to have

I'd extend "afternoon" to "half a week", but in general I agree with OP. > Yes, I can write a hashtable implementation in an afternoon, but it's going to have bugs that I'll spend the next year fixing, and still not achieve the performance of the pre-built version. The meaning of "afternoon work" should be considered "of good enough quality". Tests, structure, reasonable docs, all that. It shouldn't be a fastest written something, it should be a normal code. > and still not achieve the performance of the pre-built version. Some losses in performance are acceptable for greater visibility and better fit for the project. If you need non-trivial performance gains - well, those are also achievable by code, are you sure you can actually write such code in a few days? > Find a bug in the dependency? Submit a patch. That's the point. To submit a good patch, you have to internalize the system. It's easier to do if the system is yours - doesn't do much except what you need. > Worried about the dependency changing? Lock the version. Now you've locked yourself out of upstream bug fixes. > Don't reinvent the wheel. Here is a wheel patented in 1972 in US, with noticeable benefits over the traditional idea: https://en.wikipedia.org/wiki/Mecanum_wheel https://en.wikipedia.org/wiki/Mecanum_wheel :) . We do reinvent the wheel whenever we need to have an actual wheel for a device, not an abstract concept. Similarly, we write for loops, "reinventing" them for our specific purpose. Those are all different wheels, loops and needs. Don't mistake the "idea" of a hashtable with an implementation.