This is in continuation with my last presentation about pragmatic programmer. In this I will be discussing the next 10 tips of the book Pramatic Programmer. I hope you will enjoy

1. Pragmatic Programmer - 2
By -: Uday Pratap Singh

2. Agenda
 DRY
 Duplication
 Orthogonality
 Estimation
 Debugging

3. What we do ........

Collect , organize, maintain
knowledge.

Documents knowledge.

Make it come alive in running code.

Test what have been done with our
knowledge.

4. Knowledge isn't stable

Changes after a meeting with client.

Change in the business rule.

Changes because test showed the
problem with our knowledge.

5. Common assumption

Maintenance begins when application
released.

Maintenance means fixing bugs and
enhancing features.

6. What maintenance means

It's not a discrete activity but a
routine part of development process.

Code should be changed with the
change in our knowledge.

7. Tip

Tip 11

There are no final decisions

8. Maintenance is a very difficult
task if your code is not
DRY

9. Tip

Tip 12

Don't repeat yourself

10. Duplication

Imposed – It’s the environment

Diff languages, code,
documentation and comments.

Inadvertent – Developers didn’t
realize

Truck, Driver and DeliveryRoute
(Distribution industry)

11. Duplication

Impatient – Lazy developers

Why not copy paste the existing code
or class. It needs discipline and
willingness to save pain later

Inter-developer duplication

Encourage active and frequent
communication between developers

12. Tip

Tip 13

Make it easy to Reuse

13. Orthogonality

Two or more things are orthogonal if
changes in one do not affect any other.

14. Benefits of orthogonality

Forces the developer to write
independent and small code.

Reduces development time and testing

Reusable code.

Frequency of change in small code is
relatively less than a Bigger piece of
code.

Easier to slice out diseased sections of
code.

15. Tip

Tip 14

Eliminate effects between unrelated
things

16. Estimating

Anything can be estimated even with
missing information only if you are
comfortable with estimation.

Everyone can estimate its just some
are more accurate than other.

Estimation is always contextual.

Estimating the value of pie differs in
different context.

Ask someone who has already done it.

17. Estimating

Understand what's being asked.

Build a model of the system.

Break the model into component.

Give points to each component.

Keep track of your estimation.

18. Tip

Tip 15

Estimate to avoid surprises

Tip 16

Iterate the schedule with code

19. Debugging
It is a painful thing to look at your
own trouble and know that you
yourself and no one else has made it.
- Sophocles

20. Debugging

Do not describe bug as “Object of terror”.

Computer systems do what you tell them to
do, not necessarily what you want them to do.

No one writes a perfect software.

Debugging is just a problem solving, do not
make it a emotional subject.

Do not spend time and energy laying blame on
who created the bug.

It doesn't matter the bug is your fault or
someone else's. It is still your problem.

21. Tip

Tip 17

Fix the problem, Not the Blame

22. Debugging mindset
The easiest person to deceive is one's
self
- Edward Bulwer

23. Debugging mindset

Turn off your defences you use each
day to protect your ego.

Turn out any project pressure.

Get yourself comfortable.

Don't say “it cant happen” because
quite clearly it can, and has.

24. Tip

Tip 18

Don't panic

25. Debugging Strategy

Try to reproduce it.

Get the full and detailed information from
bug reporter.

If you are lost try to explain it to someone
else.

The bug might be because of third party tool
but it should not be your first thought.

If your small change breaks the system than
its most likely the small change responsible
for it no matter how farfetched it seems to
be.

26. Tip

Tip 19

“Select” isn't Broken

Tip 20

Don’t assume it – Prove it

27. Thank You!