4 ms·

> make it “generic enough to handle future use cases”. The answer to this is usually YAGNI. That is, don’t plan for a future you might never have. Code in a w

> make it “generic enough to handle future use cases”. The answer to this is usually YAGNI. That is, don’t plan for a future you might never have. Code in a way that won’t back you into a corner, but you don’t know what the future’s cases might be (or if there even will be any) so you can’t possibly design in a generic way to handle them. Often you just end up with over-engineered generec-ness that doesn’t actually handle the future cases when they crop up. Better to wait until they do come up to refactor or redesign. Some people argue to design in a way that lets you rewrite and replace parts of the system easily instead.

kazinator 7y ago
The repetition is what is YAGNI! Repeating code 7 times in preparation for separate evolution of those 7 cases is YAGNI, unless the requirements are on the table now. Merging repeated code into one is something that is demonstrably needed now, not later.
- dkersten 7y ago
  Yes, I agree. That’s not what I was replying to, though. I noted in another comment that I consider merging worthwhile even in the absence of three use cases, certainly if what you have now is very similar.
  - scarface74 7y ago
    If all seven are the same except for one or two cases, it doesn’t mean that you have to have a bunch of if statements, you either use inheritance or composition to create special cases and judiciously apply “pull members up” and “push members down” refactoring, interfaces, abstract classes, virtual methods, etc. These are all solved problems. Yes I know about the whole “a square is not a rectangle problem”.
- jfengel 7y ago
  It's not so much that you're preparing for 7 separate cases, as a thing that works in one place and almost, but not quite, fits in 6 others. You rarely exactly duplicate code, but often duplicate and modify. By the time you hit 7, you do clearly Need It. But now you've got 7 cases to work from in writing the generalization. When the number is 2, it's often reasonable to say, "I don't know how these will evolve and I'll probably guess wrong".

kazinator 7y ago

The repetition is what is YAGNI! Repeating code 7 times in preparation for separate evolution of those 7 cases is YAGNI, unless the requirements are on the table now. Merging repeated code into one is something that is demonstrably needed now, not later.

dkersten 7y ago
Yes, I agree. That’s not what I was replying to, though. I noted in another comment that I consider merging worthwhile even in the absence of three use cases, certainly if what you have now is very similar.
- scarface74 7y ago
  If all seven are the same except for one or two cases, it doesn’t mean that you have to have a bunch of if statements, you either use inheritance or composition to create special cases and judiciously apply “pull members up” and “push members down” refactoring, interfaces, abstract classes, virtual methods, etc. These are all solved problems. Yes I know about the whole “a square is not a rectangle problem”.
jfengel 7y ago
It's not so much that you're preparing for 7 separate cases, as a thing that works in one place and almost, but not quite, fits in 6 others. You rarely exactly duplicate code, but often duplicate and modify. By the time you hit 7, you do clearly Need It. But now you've got 7 cases to work from in writing the generalization. When the number is 2, it's often reasonable to say, "I don't know how these will evolve and I'll probably guess wrong".