5 ms·

Concerning generic code, I think we should use a rule inspired from the quote attributed to Einstein "Everything should be made as simple as possible, but not s

by Rexxar 12y ago

Concerning generic code, I think we should use a rule inspired from the quote attributed to Einstein "Everything should be made as simple as possible, but not simpler". The generic code rule : "Everything should be made as generic as possible, but not more generic than necessary". That means that every time we see a pattern in the code, we can try to write a generic version. Be that we should never try to do a generic version of something if we don't need it somewhere in the code. This rule respect, IMHO, both DRY and YAGNI principle.

jrochkind1 12y ago
I wonder if the converse guideline would actually be more useful: Everything should be made no more generic/abstract than actually neccesary. Phrasing it as "should be made as generic as possible" is just what leads us down the primrose path to over-engineered complexity, no? Abstraction maybe doesn't at first seem to use like it should be the enemy of simplicity -- certainly we can think of cases where abstraction leads to beautiful simplicity, and that's in fact a large part of what makes software engineering work, and what we enjoy about it. But in actual life, the pursuit of "as generic as possible" (even if qualified by 'not more generic than necessary") seems to often be the primary motivation leading to conflict with "as simple as possible but not simpler."
- chriswarbo 12y ago
  You've made a subtle change of meaning there. By going from: > should be made as generic as possible To: > should be made no more generic/abstract than actually neccesary. You've introduced a subjective judgment call. The result is a tautology, since we could rephrase it to: > should be made no more generic/abstract than it should Whether or not we agree with the quotes from Einstein or the parent, at least they're (mostly) objective, and tell us how to proceed: if anyone finds a way to simplify or generalise a result (without sacrificing correctness), they should do it.
  - jrochkind1 12y ago
    I don't know if it's any different in objective/subjective, I think, as applied to software engineering, anyway, there's always a subjective element. I suppose the corresponding operationalization to the way I've phrased it is: Don't add genericness unless you are unable to find a way to proceed with what is needed without it. I think (and I think the OP thinks) the problem we have more often is people adding too much abstraction, not too little. If so, we need a rule that discourages, rather than encourages, the problem.
benihana 12y ago
I don't think that's a rule so much a consequence of following DRY and YAGNI to the letter. If you don't make something until you need it, and you don't repeat yourself, by definition, you'll make generic solutions for when they're needed. The issue isn't the concept and understanding it, the issue is that it's hardly ever straightforward to figure out if you need something, or if refactoring your copy/pasted code so you're not repeating yourself is worth the effort, given there are other things that need to be done. The hard part about software is balancing the tradeoffs between time, money, technical challenges, product challenges, not the ground rules.

by Rexxar 12y ago

jrochkind1 12y ago

I wonder if the converse guideline would actually be more useful: Everything should be made no more generic/abstract than actually neccesary. Phrasing it as "should be made as generic as possible" is just what leads us down the primrose path to over-engineered complexity, no? Abstraction maybe doesn't at first seem to use like it should be the enemy of simplicity -- certainly we can think of cases where abstraction leads to beautiful simplicity, and that's in fact a large part of what makes software engineering work, and what we enjoy about it. But in actual life, the pursuit of "as generic as possible" (even if qualified by 'not more generic than necessary") seems to often be the primary motivation leading to conflict with "as simple as possible but not simpler."

chriswarbo 12y ago
You've made a subtle change of meaning there. By going from: > should be made as generic as possible To: > should be made no more generic/abstract than actually neccesary. You've introduced a subjective judgment call. The result is a tautology, since we could rephrase it to: > should be made no more generic/abstract than it should Whether or not we agree with the quotes from Einstein or the parent, at least they're (mostly) objective, and tell us how to proceed: if anyone finds a way to simplify or generalise a result (without sacrificing correctness), they should do it.
- jrochkind1 12y ago
  I don't know if it's any different in objective/subjective, I think, as applied to software engineering, anyway, there's always a subjective element. I suppose the corresponding operationalization to the way I've phrased it is: Don't add genericness unless you are unable to find a way to proceed with what is needed without it. I think (and I think the OP thinks) the problem we have more often is people adding too much abstraction, not too little. If so, we need a rule that discourages, rather than encourages, the problem.

benihana 12y ago

I don't think that's a rule so much a consequence of following DRY and YAGNI to the letter. If you don't make something until you need it, and you don't repeat yourself, by definition, you'll make generic solutions for when they're needed. The issue isn't the concept and understanding it, the issue is that it's hardly ever straightforward to figure out if you need something, or if refactoring your copy/pasted code so you're not repeating yourself is worth the effort, given there are other things that need to be done. The hard part about software is balancing the tradeoffs between time, money, technical challenges, product challenges, not the ground rules.