Software Development Principles

Outline of common, popular Software Development Principles

Get Started. It's Free
or sign up with your email address
Rocket clouds
Software Development Principles by Mind Map: Software Development Principles

1. D.R.Y.

1.1. Don't

1.1.1. Don't

1.2. Repeat

1.2.1. Repeat

1.3. Yourself

1.3.1. Yourself

2. K.I.S.S.

2.1. Keep

2.2. It

2.3. Simple

2.4. Stupid

2.5. Great advice. Hurts my feelings every time.

2.6. Enterprise Quality FizzBuzz

3. Object-Oriented Programming Principles

3.1. Abstraction

3.2. Inheritance

3.3. Polymorphism

4. S.O.L.I.D.

4.1. SRP

4.1.1. Single Responsibility Principle

4.2. OCP

4.2.1. Open-Closed Principle

4.3. LSP

4.3.1. Liskov Substitution Principle

4.4. ISP

4.4.1. Interface Segregation Principle

4.5. DIP

4.5.1. Dependency Inversion Principle

5. Y.A.G.N.I

5.1. You

5.2. Ain't

5.3. Gonna

5.4. Need

5.5. It

6. Why Should I Care What Color the Bikeshed Is?

6.1. AKA

6.1.1. Law of Triviality

6.1.2. Parkinson's Law of Triviality

6.1.2.1. Not to be confused with Parkinson's Law

6.1.2.1.1. Parkinson's Law vs. Parkinson's Law of Triviality

6.1.2.1.2. Or, Law of Triviality vs. Parkinson's Law

6.1.3. bicycle-shed effect

6.1.4. bike-shed effect

6.1.5. bike-shedding

6.2. People give disproportionate weight to trivial issues.

6.3. Design discussions are usually incorrectly focused on syntax rather than semantics

6.3.1. Difference between syntax and semantics in programming

6.3.1.1. Semantics

6.3.1.1.1. Whether it has meaning (or at least a logical meaning and is represented in code as such)

6.3.1.2. Syntax

6.3.1.2.1. Whether it's correct or valid for the grammar of the language

7. Parkinson's Law

7.1. "Work expands so as to fill the time available for its completion"

7.2. NOT TRIVIAL

7.2.1. 'Triviality' is not involved in this definition at all. Easy to distinguish if you separate them out via this word.

8. Sayre's Law

8.1. "In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake."

9. Design by Contract

10. Worse Is Better

10.1. Sometimes removing functionality and thus simplifying the product and user-experience is better than increased functionality.

10.2. Increased functionality does not always mean better.

11. Defensive Programming

12. Offensive Prorgramming

13. Separation of Concerns

14. Information Hiding

15. Law of Demeter

16. Ninety-nine Rule

17. Coupling

17.1. Loose Coupling

17.2. Tight Coupling

18. Fail-fast

19. Boy Scout Rule

19.1. “Always leave the campground cleaner than you found it.”

20. CodingHorror's Less Serious Additions to the Lexicon NOT REALLY PRINCIPLES

20.1. Smurf Naming Convention

20.1.1. When everything is prefixed with the same word

20.1.1.1. SmurfController

20.1.1.2. SmurfAccountPage

20.2. Rubber Ducking

20.2.1. Talking a problem out to someone or something but not actually getting any response yet still either illuminating or totally solving it

20.3. Ninja Comments

20.3.1. Zero comments

20.3.2. AKA "Secret comments"

20.3.3. AKA "Hidden comments"

20.4. Lochness Monster Bug

20.4.1. Not reproducible

20.4.2. Seen by one person

20.5. Atwood's Duck

20.5.1. A purposefully 'lame' feature added to the product that you demo to a client.

20.5.2. Meant to allow for them to remove it and thus feel like they are contributing.

20.5.3. Lessens the possibility that they'll argue other more important items.

20.6. Fear-Driven Development

20.6.1. When project management adds more pressure

20.7. Baklava Code

20.7.1. if(thing1){ if(thing2){ if(thing3){ if(thing4){ // keeps going } } } }

20.8. Jimmy

20.8.1. Shitty new developer

20.9. Doctype Decoration

20.9.1. "When web designers add a doctype declaration but don't bother to write valid markup."

20.10. Yoda Conditions

20.10.1. if(5 == five)

21. Inversion of Control

22. https://en.wikipedia.org/wiki/Category:Programming_principles

23. https://github.com/webpro/programming-principles

24. 97 Things Every Programmer Should Know

24.1. Distilled down version by random person