> Time for a pop quiz. I was already answering "it depends" on three of them. > 1. Code Reuse is: "Code reuse" sounds good, but if you abuse DRY ("Don't Repe

> Time for a pop quiz. I was already answering "it depends" on three of them. > 1. Code Reuse is: "Code reuse" sounds good, but if you abuse DRY ("Don't Repeat Yourself") then you can easily get into a mess that would have been more maintainable if it had been separate structs/classes/functions/modules in the first place, even if there's some duplicate code. My rule of thumb is, if the purposes are different, then they should be separate things, even if the code is exactly the same line-for-line. When (if) it becomes obvious that we're always updating the code on multiple sides, then we can start considering combining them into only one thing. It more or less aligns with the Rule of Three. > 2. Reinventing the Wheel is: It sounds "bad" because there's apparently "duplicate effort that you could have saved if you just used this library", but you have to remember that now you're at the mercy of this library, and unless you're paying for it, the maintainers can do whatever they want with it, including removing it or even using the name for a different thing (e.g. "tree-analyzer" being initially something related to ASTs (Abstract Syntax Trees), but then being re-purposed as an OpenCV tool to identify tree species (plants) from pictures). And also following the wheel analogy, we can't forget that reinventing the wheel was necessary because modern cars can't use wheels destined for horse carriages; and airplanes can't use wheels used by cars. It wasn't just a matter of making an existing wheel thicker, or just using a different material; the whole build process is different. > 3. The Not-Invented-Here Syndrome is: The article sums this up nicely: "If it’s a core business function — do it yourself, no matter what."