4 ms·
If things needs to evolve to separate direction, you can duplicate them. Unreasonable X is unreasonable, that's true no matter X but that's not very insightful
by temac 7y ago
If things needs to evolve to separate direction, you can duplicate them.
Unreasonable X is unreasonable, that's true no matter X but that's not very insightful. Unreasonable factorizing is unreasonable. So are unreasonable copy pasts.
Now a good question can be: would I "prefer" one or the other gone too far? That's merely a personal preference question, and on my side I've got a clear answer: I prefer something a little bit too abstract, to something a little bit too copy pasted. Because while abstract I still can understand more of the system more quickly, whereas duplicated I basically have to start by reading a lot more and factorizing (possibly in my head) before getting to a balanced situation...
Your own preference may vary, but I've yet to see a system maintained correctly by people copy pasting too much and not caring about anything but the one example they have to handle (because e.g. of a workflow described in a ticket).
Things can be accidentally similar, but WAY more often in copy pasted code-bases they are accidentally diverging, and that multiply the time I spend on that kind of mess by a factor that is probably near 10.
- darkerside 7y agoProblem with abstractions is, once they exist, people assume they are meaningful.
- deleted 7y ago[deleted]
- gmueckl 7y agoThat is because proving that it isn't is a major task that involves dissecting the codebase, its current specs and planned future features (a seemingly pointless abstraction now can be the groundwork for a new module that will appear soon[0]). Thus the asymmetry between adding and removing abstractions. [0] where soon either means really soon because product management needs it yesterday or never because there is too much work to do in other places.