Comment by osigurdson
4 days ago
You mean to future proof the code so requirements changes are easy to implement? Yeah, I've seen lots of code like that (some of it written by myself). Usually the envisioned future never materializes unfortunately.
4 days ago
You mean to future proof the code so requirements changes are easy to implement? Yeah, I've seen lots of code like that (some of it written by myself). Usually the envisioned future never materializes unfortunately.
I mean given that you've had this problem repeatedly, I'd call it "past-proofing", but I suppose you know your codebase better than I do.
There’s always a balance to be struck when avoiding premature consolidation of repeated code. We all face the same issue as osigurdson at some point and the productive responses fall in a range.
If you have some idea of what future changes may be seen, it is fine to design for that. However, it is impossible to design a codebase to handle any change. Realistically, just doing the absolute bare minimum is probably the best defence in that situation.