On DRY and the cost of wrongful abstractions
<i>Yes, you read that right. Duplicating code (a.k.a copy + paste) can be a good thing. Namely when the abstraction that would replace repetitive portions of your codebase is a pain to understand.</i><p>Yes, this 1000 times! DRY or any pattern&#x2F;principle is not some sort of universal truth&#x2F;declaration of ultimate goodness from your deity or some deep law like the Heisenburg Uncertainty Principle! <i>It&#x27;s just a rule of thumb</i>. As a practical technologist, you must always implement with respect to the <i>contextual cost&#x2F;benefit</i>. Taking any principle as an automatic ultimate good is simply intellectual laziness!<p>I was in a company with a Java product and a Smalltalk product. The Smalltalk product was rather well factored. We had a policy of rewrites to keep things architectually clean. We had the <i>fantastic</i> Smalltalk Refactoring Browser as our IDE, and we weren&#x27;t afraid to use it. (To this day, you can refactor an order of magnitude or more faster with it than you can in other languages.) The Java product consisted of many independent parts with tons of duplicated code between them. Definitely not DRY. (There were also 20X more Java programmers than Smalltalk, for a comparable product.)<p>One thing I noticed, is that bugs on the Java side were more prevalent, but never affected the entire application. Whereas, the far better factored Smalltalk product could occasionally have the rug pulled out from underneath the entire application by the introduction of a library bug. (Though it would be very rapidly fixed.)<p>Another thing at that shop: We had a policy of only empirically verified DRY. We never wrote code to DRY in anticipation: only in response to actual code duplication. Generally, actual practice and experience is better at producing exactly the needed architecture than the prognosticating cleverness of programmers.<p>EDIT: Shower thought! (Yes, I literally got out of the shower just now.) There is a lot of <i>emphatic</i> but somewhat thoughtless application of principles and rules of thumb because it&#x27;s actually motivated by <i>signalling</i>. The priority is actually on the <i>opportunity to signal</i> and not on the underlying cost&#x2F;benefit calculation. There is a nice analogy for this in music. Once a musical scene gets a certain degree of prominence and&#x2F;or commercial success, people start prioritizing sending the signal that they are part of that musical scene. So you will find bands and musicians using those techniques and stylistic flourishes, not because of the underlying aesthetic principles in support of the particular piece of music, but as <i>an opportunity to signal</i>. This happens in OO and also in the startup scene. (And, OMG, but is <i>signalling</i> given a lot of energy in the Bay Area!)<p>So the insider move is this: Look for the underlying motivation behind the signal. Did this person jump on the opportunity to signal, or did they first seek out the information to make the determination of cost&#x2F;benefit? How carefully did they do that? (Hopefully, we can get some of the hipsters&#x2F;pretenders to at least go through the motion of doing the above. Even just going through those motions turns out to be beneficial.)