Anti-pattern: more is less

This anti-pattern underlies most anti-patterns : "more is less" instead of "less is more". This is particularly in the excessive frameworks anti-pattern.

The term "less is more" was popularized by minimalist architect Ludwig Mies van der Rohe.

The general rule is don't build systems on top of complex parts. Complex parts are not "more" they are "less" e.g. less useful/flexible/performant etc. Complex parts have an unfortunate habit of creating problems that wouldn't have been there in the first place.

In general, one should try to write code that is as free from irrelevant concerns as possible. That means most code should be "pure CPU" on pure state machines and data structures. That means code with no dependencies either directly or indirectly on the following:

Ideally most code is deterministically testable, infallible, and inevitably free from racing conditions (see the thread-safe datatypes anti-pattern). Coders that can achieve this (even in systems that ultimately handle GUI events, messages, access databases etc) have reached a kind of "enlightenment". Sadly it's surprisingly rare.

Dependency injection [] is a useful idea. Unfortunately it makes it easier to write modular code (i.e. a partition of the code into modules with low coupling and high cohesion) without an emphasis on modules involving pure CPU on pure data structures and statically defined behaviour.

Udi Dahan's blog post Build one to throw away claims throw-away prototyping is a good idea:

...at the beginning of these projects, often our users or customers don’t exactly know what they want. ... This is one of the advantages of an agile approach that focuses on getting working software in the hands of users very early. ... The mistake here is believing that this needs to be done in a production-ready manner, using all of the super-scalability and highly reliable infrastructural elements in our target deployment environment.

The real mistake here is believing that most code that needs to be written in a production-ready manner needs to use "super-scalability and highly reliable infrastructural elements" in the first place. Instead most of the code should be pure CPU on pure in-memory data structures. The only difference between it being production-ready or a prototype should be the extent to which it has been refined, tested and documented.

Throw-away prototyping is less important when one tends to make the majority of the code pure CPU on pure data structures in the first place.