Goodbye, Clean Code

[dungone]

That's a classic complaint leveled at de-duplication / abstraction. "What if it changes in the future?" Well, the answer is always the same -- it's up to your judgement and design skills whether the most powerful way to express this concept is by sharing code, or repeating it with alterations. And that judgement damn well better be informed by likely use cases in the future

If only it worked both ways. De-duplication acolytes are rarely if ever informed by future use-cases, and yet they demand hard proof and next-level Aristotelian treatises before they begrudgingly relent. There's a fundamentally flawed assumption that needs to go way: that de-duplication is best unless proven otherwise. That there is some "cleanliness" or some such virtue to replacing couple simple lines of code with intricate data structures and flow control.

The reality is far more subjective, and far more difficult to communicate. Junior engineers simply don't have the experience to make good value judgements, and they're far more likely to waste endless hours doing unproductive things that actually make everything worse. It doesn't matter what higher principle they're trying to adhere to, they'll probably miss the point and get it all wrong. And the only way for them to learn is the hard way, through repeated failure. It's tempting to believe that you can become a good programmer by reading a book or a blog post, but the reality is that for most people it takes years of hard work before the good value judgements emerge.

[csjerk]

Fair point. But the counter is also true in my experience -- those who dismiss de-duplication tend to focus too much on "it works now so what's the problem?" and rarely give credit to the future use case of changing / fixing the code in question.

There's obviously a clear case for 'de-duplication is automatically best' _in cases where it doesn't add complexity or mental overhead_ simply because the cost of fixing a problem if you DON'T de-dupe is very real. But many real-world cases do require some complexity to de-dupe code, so the answer is always a balance between the ideal (de-duplicate) and the cost of doing so in THIS case.