Core Design Principles

Core Design Principles for Software Developers by Venkat Subramaniam

Devoxx is a conference directed towards the Java, Android and HTML5 community.

Some points that are language agnostic, and can be applied universally are summarized below:

  1. Good code can be changed without much hassle.
  2. It is always impossible to get it right the first time.
  3. Be unemotional in coding.
  4. People who are dangerous to work with (So you shouldn’t become them): People who can’t follow instructions, and people who only follow instructions.
  5. Take time to review code. (You can learn, and you can improve the design)
  6. Simplicity is hard. Strive to achieve that.
  7. Simple keeps you focused (Imperative vs Declarative)
  8. Write code to solve real problems. (Don’t code without knowing what it should do)
  9. Complexity (Inherent vs Accidental). Inherent Complexity comes from the problem. Accidental Complexity comes from the solution.
  10. Simple != Familiar (just because you know what it does, doesn’t mean its simple)
  11. Good Design is one that hides Inherent complexity, and eliminates Accidental Complexity
  12. YAGNIy (You Aren’t Going To Need It (yet)) Don’t implement things that you don’t need yet. Do the important things first.
  13. Cost of implementing now > Cost of implementing later = Postpone
  14. Cost of implementing now = Cost of implementing later = Postpone
  15. Cost of implementing now < Cost of implementing later = Do it now
  16. Have a Good Automated Testing. This prevents fear of postponing
  17. Cohesion is a code that does one thing and one thing only. This makes it easier for change.
  18. Similar code stays together. Dissimilar code stays away
  19. Coupling is what you depend on. Try to see if you can remove coupling. (You can’t remove all dependencies, so make them loose)
  20. Knock out before you Mock out
  21. Good Design has High Cohesion and Low Coupling
  22. DRY (Don’t repeat yourself) (Don’t duplicate code, and effort)
  23. Every piece of knowledge in a system should have a single unambiguous authoritative representation
  24. CPD (Copy Paste Detector to find duplicated code)
  25. Don’t write overly long functions and methods
  26. How long is a long method? SLAP (Single Level of Abstraction Principle)
  27. SLAP: What was the level of abstraction of your function
  28. Don’t comment what, comment why
  29. Open Closed Principle: A software module should be open for extension, but close for modification
  30. Use DRY and YAGNI often

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s