Chapter 5 - Design in Construction

Code Complete - 5.2. Sotfware's Primary Technical Imperative: Managing Complexity

Once you understand that all other technical goals in software are secondary to managing complexity, many design considerations become straightforward.

I noticed how this thought influenced me when I check commit diffs. If the code is not simpler, I'm not satisfied.

You might think of this as mental juggling - the more mental balls the program requires you to keep in the air at once, the more likely you'll drop one of the balls, leading to a design or coding error.

(...) If your design doesn't let you safely ignore most other parts of the program when you're immersed in one specific part, the design isn't doing its job.

Complexity is one of the reasons for project failure:

When projects fail for reasons that are primarily technical, the reason is often uncontrolled complexity. The software is allowed to grow so complex that no one really knows what it does. When a project reaches the point at which no one completely understands the impact that code changes in one area will have on other areas, progress grinds to a halt.

Desirable Characteristics of a Design