[antirez]

I can't disagree more with this post. One should always aim at trivial code, but as things get more complex, it is there the the sensibility should fire in and make you say, ok I need more abstraction now, and refactor accordingly. But even then it is important to just add the minimum amount of abstraction to generalize the problem at hand, without thinking like "but why if in the future we change things..." Unless it's very clearly going to happen soon.

[auxbuss]

There's an excellent discussion on this topic in the sample chapter, Rediscovering Simplicity[0], from Sandi Metz's book, 99 Bottles of OOP[1]. I often use it as a source for discussion with devs.

[0] https://www.sandimetz.com/99bottles/sample

[1] https://www.sandimetz.com/99bottles

[ScottBurson]

I like this, though I think anyone who mentions SLoC as a metric is honor-bound to quote Dijkstra: My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

[SNACKeR99]

I find this true, and depressing at the same time. The amount of curation needed for a constantly evolving code base is vastly underestimated by most, even to achieve the modest design goals (IMO) that you are espousing.

[antirez]

Yep, you have to babysit the code forever or it dies...

[m12k]

I agree, generalize too early, and you are just as likely to overengineer, anticipate changes that never come (YAGNI), constrain the code in other ways that turn out to be unwieldy and incur the mental overhead of a more complex design that each new reader of the code needs to understand. Generalization should mostly happen during refactoring.