Software Development Principles
Outline of common, popular 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
3.4. Encapsulation
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.7.2. Baklava code is an IT term for code that is too complex, specifically, a code base that has too many layers of abstraction or architectural layers.
20.7.2.1. Code with too many layers
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)