QOTW: “Rampant Genericness”

Thanks to the tyranny of distance, I didn't make it over to Agile Australia this year, so I enthusiastically pored through the context-unencumbered presentations when they were posted online. Part of Neal Ford’s presentation on emergent design discussed the phenomenon of Rampant Genericness - a term I hadn’t heard used before and instantly fell in love with. Partly because I’m fond of ‘rampant’, and partly because it exactly sums up a malaise I’ve witnessed too much of over the years.

“The last of the overarching concerns for architecture and design is a phrase I've made up called rampant genericness. We seem to have a disease in the Java world: overengineering solutions by trying to make them as generic as possible. The motivation for this is clear: If we build in lots of layers for extension, we can more easily build more onto it later. However, this is a dangerous trap. Because genericness adds entropy, you damage your ability to evolve the design in interesting ways early in the project. Adding too much flexibility makes every change to the code base more complex.” (from http://www.ibm.com/developerworks/java/library/j-eaed1/index.html)

I’ve recently been doing some work for a client who have elevated a love of genericness to an almost religious observance. A relatively small, straightforward WinForms client application had an overabundance of layers (what I’ll dub the MVPCVM pattern) where each class in each layer had a separate interface. Adding basic extra functionality typically involved touching a minimum of 8 or more code files (not including the form). Needless to say, any prospect of modifying the design tended to instantly get too-hard-basketed.