Simplicity comes from the use of a small number of concepts on a large number of problems.

Design patterns provide a large number of concepts to use on similar problems.

It is easy to understand something complex, if that something can be divided into smaller entities that behave similarly or share a basic design concept to the larger entity. I would call such a thing highly organized.

It is much more difficult if when you divide something the smaller entities all have their own behavioural complexity or underlying design, which bears no resemblance to each other or to the larger part. It becomes orders of magnitude more complex to reason over the whole and what behaviour might emerge from it. I would call such an entity to be highly disorganized.

Most software today falls into the latter category. I will not blame design patterns, they are an answer to the problem they set out to solve. I just think that the problem is incorrectly defined.

Design patterns give you a tool to manage complexity. For each specific problemthere is a design pattern that has been well though out and proven to work. Unfortunately this is assumed to mean that for each problem you should use the best fitting design pattern - independant of the larger scale context of the problem.

In other words by design software systems this way you can at each step understand how a certain design concept - a design pattern - helps to create a well functioning and reusable component part. However the holistic understanding of the whole of the system becomes increasingly more difficult with every added design pattern that makes up the whole.

The human brain - at least mine - is incapable of keeping all these design philosophies in my mind at the same time. So what happens is that I compartimentalize such a system and think only of a small part. But how it fits into the larger system becomes more vague and when I go up the abstraction scale I must re-aquaint myself with any number of different design philosophies. This switching between modes of thinking - between theories of how something should work - makes my job needlessly complex.

So I think another - more important - quality of design is unity of concept. Not necessarily simplicty, but similarity. At every level of abstraction - not each but every level - the design approach should use very few very similar concepts. Once you grasp those concepts, you can grasp every part of the design either in itself or its place in the whole.

Design patterns lead smart programmers to look at any problem in isolation and search for the perfect design pattern to apply to this problem. Which theoretically makes for the perfect component. Unfortunately by doing this for any non-trivial number of components any user of the system - anyone tasked with understand and extending it I mean - must understand all these design patterns and understand how they combine to form the whole. So paradoxically the search for perfection in every part leads to highly disorganized system - something few people would describe as perfect.

I do not imply that design patterns or their application are wrong - that would be missing the point. The point is that I am against trying to use many different concepts to build a coherent and understandable whole.

Design patterns in itself are not bad. The use of too many different concepts - with profound underlying design ideas - in a single context, make that context hard to understand.

By limiting yourself to a fortuitous selection of simple concepts you can build much greater systems with more complex emergent behaviour than is possible by optimizing or perfecting each component part while sacrificing the similarity of concepts.