Complexity leads to disaster. Your application should be built around simple constructs
and understandable layers, which combine to perform complex tasks. The code itself, however,
should avoid complexity at every stage. This is much easier to say than to do, though,
since many programmers are afraid of missing important pieces, or of oversimplifying.
- Justin Gehtland

Complexity sets the limits on programming

Much of programming is about reducing
software complexity. Entire software methodologies such as
structured programming and object-oriented programming
can be viewed as techniques specifically designed to limit complexity.

Complexity can be seen as similar to the problem of heat in
integrated circuits. Limits on what are practical are imposed by
certain constraints -- typically heat in an integrated circuit, and
complexity in a program. Exceed those limits and the
the component will fail. For software the complexity issue isn't one of physics or hardware
- it's about about human brains.

Complexity and the human brain

Complexity is not about
how well programs run on a machine, but about how well
humans can read and understand a program. The machine
has no problems with complexity -- the CPU dumbly
picks up the next instruction and does what
that instruction says. Then the next instruction, etc.
The CPU never needs to understand what the program does,
humans do.

The sad fact is that human minds are limited in their
ability to deal with complexity. Everyone loves to quote
Miller's Law: A person can only keep 7 plus or minus 2
items in mind at one time. It isn't much to base programming
design on, but it supports the idea that there
are real mental limits. Why can't we keep 100 things
in short term memory, or 100,000?

You will discover, if you haven't already, that there are large differences
in the ability of different programmers to deal with complexity.
I certainly don't rank at the top in being able to deal
with complexity, but I've worked with programmers who could
juggle an amazing number of items at the same time.
My "weakness" has forced me to produce
simpler designs because I don't have a choice.
The result of this limitation, ironically, often leads to better programs.
Simpler is better, but as Albert Einstein said, "Make things
as simple as possible -- but no simpler".

The constant battle against complexity takes place at
every level, from choosing a variable name to organizing
a large number of cooperating classes.
Many of the best programming practices are directly
aimed at controlling complexity.

Best practices

Being aware of the problem of complexity, and learning the best practices
for dealing with it is how this should be approached.

Measuring complexity

Software engineers have established several ways to estimate complexity.
A complexity estimate can be turned into an estimate of the cost of
writing software. Measuring complexity in existing software can identify
modules that are good candidates for refactoring.

And just having some ideas about how complexity can be measured will
give you a good idea about how to write better code.