Have you ever had a “Swiss Army Knife” component in your AEM project? Something that has many modes of behavior and many settings and is enmeshed in the current business logic? We bet you have, because we have dealt with this kind of component several times. A Swiss Army Knife can be anything, like a component that exposes individual products in a catalog in which product expositions differ from each other. It can also be a view of data that comes from different sources, each of which has a unique set up. Maybe your Swiss Army Knife is a component that has to support different adjustable layouts (like “show me these tiles as a grid, or a carousel, or a mosaic”) while working with the same data source.
No one builds a Swiss Army Knife from scratch (that would pretty clearly be against AEM best coding practices). Your component will start with a pretty compact design. It will then appear to be so handy that the business-side people will grow fond of using it and just ask to add a little tweak here, an option there… over and over and over again. The result will look great, and the component will get propagated to dozens of pages.
Everybody will see this component as a piece of cake except you, who will see a bowl of spaghetti.
At a basic level, complex code with many responsibilities ought to be split into singular elements. But when it comes to AEM components, the business side and the authors may, surprisingly, object. They generally prefer to keep working with the UI they are used to. They may loath to find a scattering of “Swiss opener,” “Swiss corkscrew,” and “Swiss little saw” where their Swiss Army Knife used to be. A greater number of separate components means more complicated template designs and policies, plus the need to migrate a multitude of legacy pages.