Software Development Principles and Best Practices

Agile Manifesto

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

12 principles behind Agile Manifesto

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
  4. Business people and developers must work together daily throughout the project
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
  7. Working software is the primary measure of progress
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
  9. Continuous attention to technical excellence and good design enhances agility
  10. Simplicity--the art of maximizing the amount of work not done--is essential
  11. The best architectures, requirements, and designs emerge from self-organizing teams
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

The Twelve-Factor App

  1. Codebase. One codebase tracked in revision control, many deploys
  2. Dependencies. Explicitly declare and isolate dependencies
  3. Config. Store config in the environment
  4. Backing services. Treat backing services as attached resources
  5. Build, release, run. Strictly separate build and run stages
  6. Processes. Execute the app as one or more stateless processes
  7. Port binding. Export services via port binding
  8. Concurrency. Scale out via the process model
  9. Disposability. Maximize robustness with fast startup and graceful shutdown
  10. Dev/prod parity. Keep development, staging, and production as similar as possible
  11. Logs. Treat logs as event streams
  12. Admin processes. Run admin/management tasks as one-off processes


  1. The Single-responsibility principle. There should never be more than one reason for a class to change or every class should have only one responsibility
  2. The Open—closed principle. Software entities should be open for extension, but closed for modification
  3. The Liskov substitution principle. Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it
  4. The Interface segregation principle. Many client-specific interfaces are better than one general-purpose interface
  5. The Dependency inversion principle. Depend upon abstractions, not concretions


Keep it simple, stupid


Don't repeat yourself


You ain't gonna need it

Eric Raymond's 17 Unix Rules

  1. Build modular programs
  2. Write readable programs
  3. Use composition
  4. Separate mechanisms from policy
  5. Write simple programs
  6. Write small programs
  7. Write transparent programs
  8. Write robust programs
  9. Make data complicated when required, not the program
  10. Build on potential users' expected knowledge
  11. Avoid unnecessary output
  12. Write programs which fail in a way that is easy to diagnose
  13. Value developer time over machine time
  14. Write abstract programs that generate code instead of writing code by hand
  15. Prototype software before polishing it
  16. Write flexible and open programs
  17. Make the program and protocols extensible