The document discusses a pragmatic approach to software development, focusing on key topics such as the evils of duplication, orthogonality, reversibility, tracer bullets, and prototypes. It emphasizes the importance of minimizing duplication and enhancing the independence of system components for better flexibility and maintainability. Additionally, it highlights the use of prototypes as a learning experience to facilitate quick development and effective problem-solving.

1. Presented by : Hakan C. İpek

2. A Pragmatic Approach
 Main Topics
 Evils of Duplication
 Orthogonality
 Reversibility
 Tracer Bullets
 Prototypes and Post-it Notes
 Domain Languages
 Estimating

3. The Evils of Duplication
 DRY – Don’t Repeat Yourself
 Every piece of knowledge must have a single,
unambiguous, authoritative representation within
system.
 If you change one, you need to change others.

4. The Evils of Duplication
 How Does Duplication Rise?
 Imposed Duplication
 Inadvernt Duplication
 Impatient Duplication
 Interdeveloper Duplication
 Make It Easy to Reuse

5. A Pragmatic Approach
 Main Topics
 Evils of Duplication
 Orthogonality
 Reversibility
 Tracer Bullets
 Prototypes and Post-it Notes
 Domain Languages
 Estimating

6. Orthogonality
 What Is Orthogonality?
 It is a critical concept if you want to produce systems
that are easy to design, build, test, and extend.
 A term of Geometry.(90 degree lines, x-y axis etc.)
 Independent lines.
 Parallel movement to an axis doesn’t change your position on
the other one.
 In computing, similar to geometry, two orthogonal
things, change in one doesn’t effect the other.

7. Orthogonality
 A Nonorthogonal System
 A Helicopter Example

8. Orthogonality
 Benefits of Orthogonality
 When components of any system are highly interdependent,
there is no such thing as a local fix.
 Eliminate Effects Between Unrelated Things
 Gain Productivity
 Reduce Risk

9. Orthogonality
 Comparing DPY with Orthogonality
 They are closely related.
 In DRY, we are looking to minimize duplication within
system.
 With orthogonality, we reduce the interpendency among the
system’s components.
 When you combine them, you’ll realize that the systems you
develop are more flexible, more understandable and easier to
debug, test and maintain.

10. A Pragmatic Approach
 Main Topics
 Evils of Duplication
 Orthogonality
 Reversibility
 Tracer Bullets
 Prototypes and Post-it Notes
 Domain Languages
 Estimating

11. Reversibility
 Nothing is more dangerous than an idea if it’s the only
one you have.
 Emil-Auguste Chartier, Propos sur la religion, 1938
 Nothing stays forever,
 if you rely heavily on some fact, you can almost
guarantee that it will change.
 Anything you do should be reversible.

12. Reversibility
 There is always more than one way to implement
something, and there is usually more than one vendor
available to provide a third-party product.
 While you writing your code, product can change.
 As time goes by, and your project progresses, you may
find yourself stuck in an untenable position.
 With every critical decision, the project team commits
to a smaller target.
 The problem is that critical decisions aren’t easily
reversible.

13. Reversibility
 Scenario;
 Early in the project, to use a relational database from
vendor A.
 Later, you discover that the database is slow, but
database from vendor B is faster.
 Most of the time, calls to third-party products are
entangled throughout the code
 But if you really abstracted the idea of a database out,
you have the flexibility to change horses in midstream.

14. Reversibility
 Mistake lies in assuming that any decision is cast in
stone.
 Instead of that, think of them more as being written in
the sand at the beach.
 A big wave can come along and wipe them out at any
time.

15. Reversibility
 Flexible Architecture
 Technologies such as CORBA can help insulate portions
of a project from changes in development language or
platform.
 Is the performance of Java on that platform not up to
expectations? Recode the client in C++, and nothing else
needs to change.
 With a CORBA architecture, you have to take a hit only
for the component you are replacing; the other
components shouldn’t be affected.

16. A Pragmatic Approach
 Main Topics
 Evils of Duplication
 Orthogonality
 Reversibility
 Tracer Bullets
 Prototypes and Post-it Notes
 Domain Languages
 Estimating

17. Tracer Bullets
 Like the gunners, you’re trying to hit a target in the
dark.
 Because you may be using algorithms, techniques,
languages, or libraries you aren’t familiar with, you face
a large number of unknowns.

18. Tracer Bullets
 Code That Glows in the Dark
 We’re looking for something that gets us from a
requirement to some aspect of the final system quickly,
visibly, and repeatably.
 Use commands to prove UI could talk to libraries.

19. Tracer Bullets
 Advantages of Tracer Code;
 Users get to see something working early.
 Developers build a structure to work in.
 You have an integration platform.
 You have something to demonstrate.
 You have a better feel for progress.
 Tracer Bullets Don’t Always Hit Their Target
 Tracer bullets show what you’re hitting. This may not always
be the target. You then adjust your aim until they’re on target.

20. A Pragmatic Approach
 Main Topics
 Evils of Duplication
 Orthogonality
 Reversibility
 Tracer Bullets
 Prototypes and Post-it Notes
 Domain Languages
 Estimating

21. Prototypes and Post-it Notes
 Prototypes are designed to answer just a few questions,
so they are much cheaper and faster to develop than
applications that go into production.
 The code can ignore unimportant details.
 If you find yourself in an environment where you
cannot give up the details, then you need to ask
yourself if you are really building a prototype at all.
Perhaps a tracer bullet style of development would be
more appropriate in this case.

22. Prototypes and Post-it Notes
 Things to Prototype
 Architecture
 New functionality in an existing system
 Structure or contents of external data
 Third-party tools or components
 Performance issues
 User interface design
 Prototyping is a learning experience. Its value lies not
in the code produced, but in the lessons learned.
That’s really the point of prototyping.

23. Prototypes and Post-it Notes
 When building a prototype, what details can you
ignore?
 Correctness
 Ex : use dummy data where appropriate.
 Completeness
 Ex : with only one preselected piece of input data and one
menu item.
 Robustness
 Ex : check error, crashes are okay
 Style

24. A Pragmatic Approach
 Main Topics
 Evils of Duplication
 Orthogonality
 Reversibility
 Tracer Bullets
 Prototypes and Post-it Notes
 Domain Languages
 Estimating

25. A Pragmatic Approach
 Main Topics
 Evils of Duplication
 Orthogonality
 Reversibility
 Tracer Bullets
 Prototypes and Post-it Notes
 Domain Languages
 Estimating