A slide about Pragmatic Approaches, such as, Evils of Duplication, Orthogonality, Reversibility, Tracer Bullets, Prototypes and Post-it Notes, Domain Languages and Estimating. Source : A Pragmatic Programmer, written by Andrew Hunt and David Thomas.

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