Software Development Philosophies slides prepared for a training.

1. Philosophy
A theory or attitude
that acts as a guiding principle
for behaviour
Praveen Nair, PMP MVP
blog.ninethsense.com

2. Any fool can write code that a computer can understand.
Good programmers write code that humans can understand.
-Martin Fowler, 2008

3. Abstraction Principle
“Each significant piece of functionality in a program
should be implemented in just one place in the source
code. Where similar functions are carried out by distinct
pieces of code, it is generally beneficial to combine them
into one by abstracting out the varying parts”

4. DRY – Don’t repeat yourself
Every piece of knowledge must have a
single, unambiguous, authoritative representation
within a system.

5. SSOT – Single Source of Truth
refers to the practice of structuring information models
and associated schemata such that every data element is
stored exactly once

6. Code Smells
any symptom in the source code of a program that
possibly indicates a deeper problem

7. Refactoring
process of restructuring existing computer code
without changing its external behavior

8. S O L I D
Guidelines that can be applied while working on software to remove code smells by causing the
programmer to refactor the software's source code until it is both legible and extensible.
1. Single Responsibility
2. Open-Closed
3. Liskov Substitution
4. Interface Segregation
5. Dependency Inversion

9. Single Responsibility Principle
every context (class, function, variable, etc.) should
have a single responsibility

10. LSP – Liskov Substitution Principle
objects in a program should be replaceable with
instances of their subtypes without altering the
correctness of that program

11. Interface Segregation Principle
no client should be forced to
depend on methods it does not use

12. Dependency Inversion Principle
Decouple software modules
• High-level modules should not depend on low-level modules.
• Abstractions should not depend on details. Details should depend on
abstractions.

13. Database Normalization
process of organizing the fields and tables of a
relational database to minimize redundancy

14. KISS – Keep it simple, stupid!
most systems work best if they are kept simple rather
than made complicated

15. YAGNI – You ain’t gonna need it
Always implement things when you actually need them,
never when you just foresee that you need them

16. Code bloat
production of code that is perceived as unnecessarily
long, slow, or otherwise wasteful of resources

17. MoSCoW
MUST
SHOULD
COULD
WON’T

18. 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.

19. Agile Manifesto
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.

20. Agile Manifesto
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.

21. Agile Manifesto
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.

22. Self-organizing team
A group of motivated individuals, who work together
toward a goal, have the ability and authority to take
decisions and readily adapt to changing demands

23. CI - Continuous Integration
Practice of merging all developer working copies with a
shared mainline several times a day. Its main aim is to
prevent integration problems (i.e., integration hell)

24. RAD
Rapid Application Development

25. UML - Unified Modeling Language
a general-purpose modeling language which is
designed to provide a standard way to visualize the
design of a system

26. UML - Unified Modeling Language
a general-purpose modeling language which is
designed to provide a standard way to visualize the
design of a system

27. TDD – Test Driven Development
first write automated test code
next write some code to pass that test

28. 80:20 rule
20 percent of the code has 80 percent of the errors.
Find them, fix them!

29. if it ain’t broke, don’t fix it
Leave something alone;
avoid attempting to correct, fix, or improve
what is already sufficient.

30. if it ain’t broke, don’t fix it
Leave something alone;
avoid attempting to correct, fix, or improve
what is already sufficient.

31. Code Reuse
Code reuse, also called software reuse, is the use of
existing software, or software knowledge,
to build new software

32. Design Patterns
a general reusable solution to a
commonly occurring problem

33. Anti Patterns
specific repeated practices that appear initially to be
beneficial, but ultimately result in bad consequences
that outweigh the hoped-for advantages

34. Architectural Patterns
a widely recognized and reused solution
to a recurring design problem

35. Quality attributes
Design Qualities
1. Conceptual Integrity
2. Maintainability
3. Reusability

36. Quality attributes
Run-time Qualities
1. Availability
2. Interoperability
3. Manageability
4. Performance
5. Reliability
6. Scalability
7. Security

37. Quality attributes
System Qualities
1. Supportability
2. Testability
User Qualities
1. Usability

38. Software Documentation
1. Requirements
2. Architecture / Design
3. Technical
4. End User
5. Marketing

39. Project Triangle
Scope
Cost Time

40. Separation of Concerns
a design principle for separating a computer
program into distinct sections