Situation: I've recently joined a new project, and I've quickly noticed that the team is very keen on keeping the code "flexible." It seems that for each class or function, they don't want to prevent the users of this framework from using things "however they want." As such, the team wants to provide multiple ways of doing the same thing.
Example: One class requires that the user provide a
render callback function. The class has a function each for accepting an interface or free function, and third template function that takes an object and pointer-to-member function. Another class repeats this pattern and has ~13
render-type functions and other suspicious looking
use functions and so on.
This philosophy is duplicated through the rest of the code. Many classes have multiple ways of doing the same thing "for your convenience." The rationale is "we don't want to make extra work for the user to force them to conform."
My response: This is a very bad philosophy with tangible negative effects.
- Code/responsibility duplication galore
- Bugs. I can see them coming. I've already found some due to the duplication.
- Confusing to new users. Why are there 13 slightly different render functions? Do they so the same thing? What's the purpose of using this one vs that one?
- Confusing to future devs - same reasons as above.
- Difficult to maintain - changing the
renderfunction means actually changing multiple
- Design takes far too long. We've spent weeks on a single UML chart of ~15 squares because keeping everything "flexible" makes things muddled and unclear. It's often "But what if it needs to do this?" or "I see, but when would we actually use this?"
- My general spidey senses tell me to be horrified.
Question: Am I right in arguing that this "flexible" philosophy is very bad design? If so, how should I convince them that making
n different ways to do every potential task is not doing the user any favors and is only making the code, in so many words, bad?