[Zibulon]

Weird. To make software more generic, I usually reduce the number of assumptions and edge case handling that goes in the APIs. If you start adding options to handle more cases, that's just not "generic". But in any case, we should start from the use cases, and avoid mission creep... and an interesting question becomes: how much do you need to design for future use cases, and how much do you need to design for the use cases currently at hand?

[the_af]

Indeed. I think the article uses the term "generic software" in a way unrelated to, say, "generic programming" (which is a good thing and, like you say, it actually means reducing assumptions). What the author probably means is "big ball of mud software that must have catch-all solutions and extension points to handle all possible cases". Unfortunately the terminology is confusing.

[Zibulon]

Sounds to me that the real issue is either mission creep, or a bad programmer/designer who doesn't see that the "generic" piece of code now needs to be split into components? In my practice, an issue that comes back often and seems to be related though, is trying to anticipate future use cases. Maybe a failure to anticipate reasonable future use cases is what leads to the mess: the first solution is not "generic" enough, and therefore more and more options are added as new use cases are discovered. But I find it hard to balance future use cases and immediate requirements.