Complexity

The more I do this software stuff, the more I think that managing project complexity is one of the keys to consistent success.

• Maintaining documentation at appropriate levels of specificity and organized logically. Good docs help you functionally understand the system at multiple levels. It should be obvious that, if you don't understand the system, you'll write some bad software.
• Using use cases, XP stories, or some other result-focused documentation to drive work. Describing software is inherently complex. Getting Earth people to understand software requirements is near impossible. Use cases or XP stories structure the requirements in terms of visible, useful features, making them far easier to understand and discuss.
• Creating well factored classes. This should be obvious, but well designed classes factor behavior and related data to one entity, making them easier to understand and change.
• Creating both dynamic and static UML describing the systems at appropriate levels of abstraction. Good UML gives you a roadmap for understanding the structure and relationships in the system. UML is succinct and has semantic meaning; it is the best thing we have for describing the basic structure of software.
• Establishing roles for project members to make responsibility clear. Clear roles let team members focus on a set of related tasks, rather than having to context-shift from hour to hour.
• Organizing meetings with as few people as possible. You have a meeting to get something done; each extra person in the meeting adds an additional line of communication, making consensus more difficult. Worst case, the extra people can't even contribute to the topics being discussed. Even worse case, the idiot who can't contribute to the meeting also can't shut up.
• Planning work in order of risk and dependency. Finishing high-risk tasks first means that more simple tasks will be left as integration draws near. Keeping dependencies straight means less re-work on already completed code.

Complexity and risk are closely related. Managing one often mitigates the other. Less-complex systems are easier to understand, easier to modify, and are less likely break in the process.

Taking the reverse, if you see a project that isn't managing its complexity, assume they will bite it at some point.