Deciding on which architectural and modular design patterns to use can be a tricky process, as usually at the time of deciding, it may not be immediately obvious what all of the requirements of the project are. Also, we as programmers are not omniscient. We are flawed, egoistic, and usually passionate individuals. This combination, if not kept in check, can yield chaotic code bases with designs that block the very productivity, reliability, and maintainability that we are trying to foster. To be wary of these pitfalls, remember the following:

• Expect change and adaptation: Every software project will involve change at some point. If we are forward-thinking in our architectural and modular designs, then we will be able to limit this future pain, but never begin a project thinking that you will create the One True Solution. Instead, iterate, question your judgment, and then iterate again.
• Consult with other programmers: Talk to the stakeholders who will have to make use of your code. That may be fellow programmers on your team or other programmers who'll be making use of the interfaces that you're providing. Field opinions and data and then make an informed decision.
• Avoid cargo culting and ego: Be aware of cargo culting and your ego and how, if we're not careful, we can blindly inherit ways of doing things without crucially considering their suitability, or we can be trapped by our egos: thinking that one specific design or methodology is perfect just because it's the one we personally know and love.
• Bias toward harmony and consistency: When designing an architecture, above all, seek harmony. There is always the possibility of many individually tailored parts of a code base, but too many internal differences can confuse maintainers and lead to a code base of splintered quality and reliability.