IMO, many times the ugliness of the code reflects the brittle thinking of the architect/designer of the application. If it is designed to expect [rigid design

IMO, many times the ugliness of the code reflects the brittle thinking of the architect/designer of the application. If it is designed to expect [rigid design] certain set of rules and not accomodate new and changing requirements, or if it is designed to accomodate unknown/made up requirements [overengineered design], you can endup with code that looks either like a framework for frameworks' sake or a perfect code for the set of known requirements. In both cases, you endup either with code that cannot easily be modified [rigid] or you endup taking many shortcuts because the original design did (and could) not anticipate new requirements [overenginnered]. One of the ways to circumvent it is to know what you need design and what you need to be able to extend without modifying the original intent.