Java: Complexity is your enemy

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.

Exponential rise in complexity with size

[To do - give data on relationship]

Next: Complexity measurement.