Practices of an Agile Developer

This card summarizes the guidelines from

Practices of an Agile Developer: Working in the Real World
(ISBN 0-9745140-8-X)
by Venkat Subramaniam and Andy Hunt.

For more information about T HE P RAGMATIC B OOKSHELF please visit

www.pragmaticprogrammer.com.

TIPS 1 TO 11

1. Blame doesnt x bugs. 7. Learn the new; unlearn the old.

Instead of pointing ngers, point When learning a new technology,
to possible solutions. Its the unlearn any old habits that might
positive outcome that counts. hold you back. After all, theres
(pg. 14) much more to a car than just a
horseless carriage. (pg. 37)
2. Dont fall for the quick hack.
Invest the energy to keep code 8. Keep asking Why.
clean and out in the open. (pg. 18) Dont just accept what youre told
at face value. Keep questioning
3. Criticize ideas, not people. until you understand the root of
Take pride in arriving at a solution the issue. (pg. 39)
rather than proving whose idea is
better. (pg. 22)
9. Tackle tasks before they
bunch up.
4. Do whats right.
Its easier to tackle common
Be honest, and have the courage
recurring tasks when you
to communicate the truth. It may
maintain steady, repeatable
be difcult at times; thats why it
intervals between events. (pg. 42)
takes courage. (pg. 25)

5. Keep up with changing 10. Let your customers decide.

technology. Developers, managers, or
You dont have to become an business analysts shouldnt make
expert at everything, but stay business-critical decisions.
aware of where the industry is Present details to business owners
headed, and plan your career and in a language they can
projects accordingly. (pg. 31) understand, and let them make
the decision. (pg. 48)
6. Raise the bar for you
and your team. 11. A good design is a map;
Use brown-bag sessions to let it evolve.
increase everyones knowledge and Design points you in the right
skills and help bring people direction. Its not the territory
together. Get the team excited itself; it shouldnt dictate the
about technologies or techniques specic route. Dont let the design
that will benet your project. (or the designer) hold you hostage.
(pg. 33) (pg. 52)

Copyright 
c 2006 Venkat Subramaniam and Andy Hunt, excerpted from Practices of an Agile Developer, ISBN 0-9745140-8-X
 TIPS 12 TO 25

12. Choose technology based 18. Estimate based on real work.

on need. Let the team actually work on the
Determine your needs rst, and current project, with the current
then evaluate the use of client, to get realistic estimates.
technologies for those specic Give the client control over their
problems. Ask critical questions features and budget. (pg. 76)
about the use of any technology,
and answer them genuinely. 19. Use automated unit tests.
(pg. 55) Good unit tests warn you about
problems immediately. Dont
13. Keep your project releasable make any design or code changes
at all times. without solid unit tests in place.
Ensure that the project is always (pg. 84)
compilable, runnable, tested, and
20. Use it before you build it.
ready to deploy at a moments
Use Test Driven Development as a
notice. (pg. 59)
design tool. It will lead you to a
more pragmatic and simpler
14. Integrate early, integrate often. design. (pg. 88)
Code integration is a major source
of risk. To mitigate that risk, start 21. Different makes a difference.
integration early and continue to Run unit tests on each supported
do it regularly. (pg. 61) platform and environment
combination, using continuous
15. Deploy your application integration tools. Actively nd
automatically from the start. problems before they nd you.
Use that deployment to install the (pg. 92)
application on arbitrary machines
with different congurations to 22. Create tests for core
test dependencies. QA should test business logic.
the deployment as well as your Have your customers verify these
application. (pg. 64) tests in isolation, and exercise
them automatically as part of your
general test runs. (pg. 94)
16. Develop in plain sight.
Keep your application in sight
23. Measure how much work is left.
(and in the customers mind)
Dont kid yourselfor your
during development. Bring
teamwith irrelevant metrics.
customers together and
Measure the backlog of work to
proactively seek their feedback
do. (pg. 97)
using demos every week or two.
(pg. 69) 24. Every complaint holds a truth.
Find the truth, and x the real
17. Develop in increments. problem. (pg. 100)
Release your product with
minimal, yet usable, chunks of 25. Write code to be clear,
functionality. Within the not clever.
development of each increment, Express your intentions clearly to
use an iterative cycle of one to the reader of the code. Unreadable
four weeks or so. (pg. 74) code isnt clever. (pg. 106)

Copyright 
c 2006 Venkat Subramaniam and Andy Hunt, excerpted from Practices of an Agile Developer, ISBN 0-9745140-8-X
 TIPS 26 TO 38

26. Comment to communicate. 32. Extend systems by

Document code using well-chosen, substituting code.
meaningful names. Use comments Add and enhance features by
to describe its purpose and substituting classes that honor
constraints. Dont use the interface contract. Delegation
commenting as a substitute for is almost always preferable to
good code. (pg. 112) inheritance. (pg. 130)

33. Maintain a log of problems and

27. Actively evaluate trade-offs. their solutions.
Consider performance, Part of xing a problem is
convenience, productivity, cost, retaining details of the solution so
and time to market. If you can nd and apply it later.
performance is adequate, then (pg. 133)
focus on improving the other
factors. Dont complicate the 34. Treat warnings as errors.
design for the sake of perceived Checking in code with warnings is
performance or elegance. (pg. 115) just as bad as checking in code
with errors or code that fails its
tests. No checked-in code should
28. Write code in short produce any warnings from the
edit/build/test cycles. build tools. (pg. 137)
Its better than coding for an
extended period of time. Youll 35. Attack problems in isolation.
create code thats clearer, simpler, Separate a problem area from its
and easier to maintain. (pg. 116) surroundings when working on it,
especially in a large application.
(pg. 140)
29. Develop the simplest solution
that works. 36. Handle or propagate all
Incorporate patterns, principles, exceptions.
and technology only if you have a Dont suppress them, even
compelling reason to use them. temporarily. Write your code with
(pg. 119) the expectation that things will
fail. (pg. 143)

30. Keep classes focused and 37. Present useful error messages.
components small. Provide an easy way to nd the
Avoid the temptation to build large details of errors. Present as much
classes or components or supporting detail as you can
miscellaneous catchall classes. about a problem when it occurs,
(pg. 122) but dont bury the user with it.
(pg. 147)

31. Tell, dont ask. 38. Use stand-up meetings.

Dont take on another objects or Stand-up meetings keep the team
components job. Tell it what to on the same page. Keep the
do, and stick to your own job. meeting short, focused, and
(pg. 125) intense. (pg. 153)

Copyright 
c 2006 Venkat Subramaniam and Andy Hunt, excerpted from Practices of an Agile Developer, ISBN 0-9745140-8-X
 TIPS 39 TO 45

39. Good design evolves from
active programmers.
Real insight comes from active
coding. Dont use architects who
dont codethey cant design
without knowing the realities of
your system. (pg. 156)
40. Emphasize collective
ownership of code.
Rotate developers across different
modules and tasks in different
areas of the system. (pg. 158)
41. Be a mentor.
Theres fun in sharing what you
knowyou gain as you give. You
motivate others to achieve better
results. You improve the overall
competence of your team. (pg. 161)
42. Give others a chance to
solve problems.
Point them in the right direction
instead of handing them solutions.
Everyone can learn something in
the process. (pg. 164)
43. Share code only when ready.
Never check in code thats not
ready for others. Deliberately
checking in code that doesnt
compile or pass its unit tests
should be considered an act of
criminal project negligence.
(pg. 166)
44. Review all code.
Code reviews are invaluable in
improving the quality of the code
and keeping the error rate low. If
done correctly, reviews can be
practical and effective. Review
code after each task, using
different developers. (pg. 170)
45. Keep others informed.
Publish your status, your ideas
and the neat things youre looking
at. Dont wait for others to ask you
the status of your work. (pg. 172)
&

www.PragmaticProgrammer.com/titles/pad

Copyright 
c 2006 Venkat Subramaniam and Andy Hunt, excerpted from Practices of an Agile Developer, ISBN 0-9745140-8-X