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 render function means actually changing multiple render-type functions.
  • 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?

  • 1
    Not knowing specifics, I would tend to agree (overbuilt, YAGNI). There should be a preferred, maybe even prescriptive way of doing things that helps users get (especially common) things done easily, automatically avoids problems and is efficient. Do you have any data on which of the ~13 ways is most popular with users, or why one might be preferred over another by the users? (I don't necessarily want the data, it's more of a yes/no question.) It seems like a lack of being in touch with actual users, though I suppose it could be fully the opposite. What language(s) are these APIs in? – Erik Eidt Feb 24 '16 at 6:17
  • I tend to agree - but not enough for a full answer. Basically the direction chosen currently ignores YAGNI and DRY and in any case I think most consumers want reasonably opinionated (prescriptive even) tooling assuming, of course, that the opinions are sensible... – Murph Feb 24 '16 at 8:53
  • There is not much I can add to my previous commentators, but one very important thing. In my mind, when I buy an API or use an OpenSource one, I await, that the developers already did the needed "what is the best", "what is the fastest", ... checks against their code. So the customer primarily pays you to make decisions for him, because he has no time, knowledge to deal with this. With this is mind, I would say, flexibility is ok, as long as you can provide it without making the code hard to maintain and of course if the given flexibility isn't against above mentioned fact. – Yosh Synergi Feb 24 '16 at 9:17
  • Strike me that polymorphism is a more general and easier to maintain approach to this issue. – adrianmcmenamin Feb 24 '16 at 20:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.