There is a constant about Software Developers : they love debating and arguing about every single aspect of the development process. Moreover, they will most likely debate forever, because there is usually nothing that can serve as a reference to tell good and bad practices apart. Want to know why ? Well.. everyone is making his own opinion based on his own vision of the truth. There is no axiom that is taken for granted and that serves as the basis for further discussion.
“In traditional logic, an axiom or postulate is a proposition that is not proved or demonstrated but considered to be either self-evident, or subject to necessary decision. Therefore, its truth is taken for granted, and serves as a starting point for deducing and inferring other (theory dependent) truths.”
The rest of the mathematical logic is based on these axioms, and given these axioms, everything else can either be proven right or wrong. While it is certainly impossible to create universal axioms and reasoning principles that cover the foundation of software development, I believe we should at least mimic the approach : decide of which design, architectural and coding principles we believe on, and then use these axiomatic principles as the foundation for decision making. Of course, the outcome of your next project will depend on the quality of these axioms, but at least you will be able to move forward and take consistent decisions throughout the lifecycle of the application. As far as I am concerned, I tend to base my reasoning on a set of axiomatic principles that are based on the opinion of respected and talented people in the software industry. Even though nothing is perfect, I believe that listening to these experienced people will more likely lead to successes than listening to any lambda developer’s opinion. This is my bet, and the rest of this post is a first draft of the main design and architectural principles that I consider my axioms.
- Domain Driven Design, Specifications pattern, Layered design.
- Principles of OOD, and in particular, the S.O.L.I.D. principles
- Clean code: A Handbook of Agile Software craftmanship.
- Implementation Patterns
- Implementation of the right Enterprise Integration Patterns that best describes a given integration issue
- Defensive Programming (also see Defensive programming in Java) and its derived principles : Design by contract, Assertions, Immutability, Copy-On-Write, Immutable collections.
- Inversion of Control
- Declarative Programming, and in particular Functional Programming-style collection manipulation and Command/Query separation, side-effect free methods.
- No premature optimization.
- Lessons learnt from UNIX programming.
- Tell don’t ask.
- Robustness principle : Be conservative in what you do, be liberal in what you accept from others.
- Do not reinvent the wheel.
The people behind these principles are smart, experienced, and potentially more intelligent than you and me together. So let’s just follow these principles for now, and once we master every single aspect of them, we will be able to help create the next generation of design and coding principles. In the meanwhile, I take these principles for granted.
