Hacker News Reader

Comment by mannykannot | Hacker News Reader

This article creates a false dichotomy. The problem is not the result of programmer A's actions, but by B's insistence on forcing his changes into the existing pattern instead of refactoring. It is irrelevant whether the original abstraction arose from deduplication.

I do agree that pressing on instead of backtracking is a cause of many problems, but the solution is not simply to proliferate duplication.

View on HN

I think the article agrees with you, but another point it makes implicitly is that programmer A is also on the hook for creating a brittle abstraction. The article is specifically warning against the temptation to deduplicate things for its own sake, without having in mind a good abstraction that describes the shared functionality implemented by the duplicated code.

You make a good point, though if A could not have anticipated the future changes, his actions may have been justified at the time. One justification that often applies to deduplication is to reduce the chance that future changes would miss one of the cases, but that only applies so long as the changes don't break the abstraction.

Avoiding brittleness is worthwhile up to a point, but overly-general abstractions often carry a cost in unnecessary complexity. From my own experience, I can think of three examples where generic programming, a container framework, and a DSL were used respectively, to create inordinately complex solutions having degrees of flexibility that would never be useful.

Reply on news.ycombinator.com