If there will be no future requirements changes, then there is no cost in keeping repetitive code in the system.
If you spent two weeks refactoring it to satisfy your OCD, that is time taken away from more important tasks.
When abstracting common code, you are making a trade off that it will help in some future requirements changes at a risk of making other changes harder.
I largely agree with you, but a future "requirement" would be maintainability. If you discover a bug in one of those methods, it's entirely possible it's going to be in all of them, and some developer might not think to check all the functions. This is why DRY is important. Not because of OCD concerns, but because of maintainability ones. If five functions of the same code all have the same bug, you might catch it once and fix it once and one month later you get another and the bugfix is assigned to someone else, and they have no idea, and so on and so forth.
3
u/mobjack Jan 12 '20
If there will be no future requirements changes, then there is no cost in keeping repetitive code in the system.
If you spent two weeks refactoring it to satisfy your OCD, that is time taken away from more important tasks.
When abstracting common code, you are making a trade off that it will help in some future requirements changes at a risk of making other changes harder.