Prefer duplication over the wrong abstraction
For a long time I&#x27;ve thought that Don&#x27;t Repeat Yourself is the most important software engineering rule. I still do, but in line with this article, I&#x27;ve learned that some things that appear to be duplication if you just look at the literal code actually aren&#x27;t. Just because you&#x27;ve got a chunk of ten or twenty lines that are identical right now doesn&#x27;t mean that they are actually identical.<p>It&#x27;s hard to give concrete examples of such an abstract concept, but one I encounter with some frequency is some chunk of code that grabs something from a URL. Assuming you&#x27;re using some half decent library that takes care of the brute mechanics, it&#x27;s easy to end up with repetitive code to deal with setting up a form and putting on a couple headers and dealing with authentication or whatever, and it&#x27;s tempting to try abstract on that yet further. Yet I find all the attempts to do so make the problem worse, because the superficially-similar code is actually quite dissimilar. The pressures on the instances are different. Here I may be deeply concerned about SSL, there I may be adding header hacks for some broken auth scheme, over there I&#x27;ve got some sort of serialization problem. Trying to put them all behind the same abstraction is just pain. It turns out the level of abstraction offered by these often years-old, mature HTTP libraries is more correct than may initially meet the eye.<p>For code to be &quot;duplicated&quot;, the full context of the code need to be duplicated, not just have superficial visual similarities. It&#x27;s important that all the code with the same context, the same evolutionary pressures, the same likely change planes end up in one place, and it is equally important that code that lacks that similarity <i>not</i> end up bound together. In the end, it&#x27;s the same error.