Software Principles

A principle is a proposition or value that is a guide for behavior or evaluation.

—Wikipedia

In software a “principle” is a general rule or law that is used to guide the design and development of software. The principles are not rules that must be followed, but rather guidelines that should be considered when designing and developing software. They are not to be ignored lightly and should be considered carefully. The principles are not to be used as a checklist, but rather as a guide to help you make the right decisions. These principles have been developed over many years of experience and are based on the best practices of the software industry. They are not the only principles that can be used, but they are the ones that have been found to be most effective.

Note

The software industry is moving fast and things change all the time. These principles are not set in stone and should be updated as needed. At least be sure that when you ignore a principle you have a good reason for doing so. Ignore them at your own risk.

Here’s a comprehensive, but slightly opinionated list of software development principles, along with brief explanations for each:

• Don’t Repeat Yourself: Avoid code duplication by extracting common functionality into reusable components. This principle promotes maintainability, readability, and reduces the risk of inconsistencies.

• Keep It Simple, Stupid: Emphasize simplicity in code and design to enhance readability, maintainability, and understanding. Complex solutions should be avoided unless absolutely necessary.

• General Responsibility Assignment Software Patterns (GRASP): General Responsibility Assignment Software Patterns provide guidelines for assigning responsibilities to classes and objects to achieve low coupling and high cohesion.

• SOLID : A set of principles guiding object-oriented design and development practices to achieve modular, maintainable, and extensible code.

  • Single Responsibility Principle: Each class should have only one reason to change, focusing on a single responsibility.

  • Open–Closed principle: Software entities should be open for extension but closed for modification, enabling behavior extension without modifying existing code.

  • Liskov substitution principle: Objects of a superclass should be replaceable with objects of its subclasses without breaking the program’s correctness.

  • Interface segregation principle: Design specific and focused interfaces to avoid forcing clients to depend on unnecessary methods.

  • Dependency inversion principle: Depend on abstractions or interfaces, not concrete implementations, to achieve loose coupling and flexibility.

• You ain’t gonna need it: Only implement functionality or code that is required at the current moment. Avoid speculative development to prevent unnecessary complexity and wasted effort.

• Law of Demeter or Principle of Least Knowledge: Limit the knowledge and communication between objects, allowing them to interact only with their immediate neighbors. This principle reduces coupling and promotes encapsulation.

• Single Source of Truth: Maintain a single, authoritative source for specific information or data within a system to ensure consistency, reliability, and ease of maintenance.

• Separation of Concerns (SoC): Divide the system into distinct and modular components, with each component handling a specific concern or responsibility. This principle improves maintainability and reduces complexity.

• Minimize Coupling and Maximizing Cohesion: Reduce dependencies and coupling between modules while maximizing cohesion within modules. This principle promotes modular design and allows for independent development and maintenance of components.

• Law of Encapsulation: Encapsulate data and behavior within a class or module, exposing only necessary and controlled interfaces. This principle promotes information hiding, data integrity, and encapsulated behavior.

• Fail Fast: Identify and report errors or issues as soon as possible to prevent the propagation of incorrect or invalid data or states.

• Convention over Configuration: Provide sensible defaults and conventions to reduce the need for explicit configuration and minimize developer effort.

• Test-Driven Development (TDD): Write automated tests before writing code to drive development, ensure correctness, and improve maintainability.

• Continuous Integration and Continuous Deployment (CI/CD): Automate the process of integrating and deploying code changes to maintain a consistent and reliable development workflow.

• Don’t Reinvent the Wheel (DRW): Leverage existing libraries, frameworks, and solutions instead of reinventing functionality that already exists. This principle promotes reuse and avoids unnecessary effort.

• Code / Design Review: Conduct thorough code reviews to ensure quality, identify issues, and provide feedback for improvement. This principle helps maintain code consistency, correctness, and knowledge sharing within a development team.

• Get rid of people who can not follow instructions: This is a principle that is often overlooked, but it is important to ensure that the team is working together effectively and efficiently.

• Get rid of people who can only follow instructions: No more no less… we are not robots.

• Software is never written but always rewritten: Test a design by making changes early.

Remember that these principles are not strict rules but rather guidelines to help developers make informed decisions and write better code. The applicability of each principle may vary depending on the context and specific project requirements.