The Pragmatic Programmer

When I was just starting out in the field, the best way to get all of us wound up (at happy hour, say) was to restart the argument, "Is software development an art or a science?" And after all of us had talked ourselves out, my team leader Larry would quietly smile and say, "But of course, it's neither: it's a craft." Larry would find lots of common ground with Andrew Hunt and David Thomas, authors of The Pragmatic Programmer: From Journeyman to Master. Their instructive, enjoyable, at times even inspiring book, published in 2000, is a blend of theory and practice. Dedicated to software engineering principles yet refusing to become enslaved by formal methods, the authors believe that it is possible to carry out a tradition of craftsmanship within an engineering discipline. In a tidy 321 pages, they have assembled a philosophy of software design and construction, illustrated with current industry best practices.

Thomas and Hunt's target reader is an object-oriented programmer in a command line environment, but the bulk of their advice applies equally well to the developer in a legacy language (and, as they point out in a footnote, "All software becomes legacy as soon as it's written") or to the practitioner in the latest whizbang development studio. Theirs is one of the most literate works in the field: they have a gift for metaphor ("tracer bullets," "broken windows," "orthogonality," "rubber ducking") and a penchant for epigraphs from sources ranging from Wittgenstein to Oscar Wilde, Santayana to Arlo Guthrie.

The authors are perhaps best known for promulgating the DRY principle—Don't Repeat Yourself:

Every piece of knowledge must have a single, unambiguous, authoritative representation in a system.

Violations of this principle, in other words, duplication, are multivalent—redundant bits of code, documentation that must explain difficult code (or worse, that contradicts it), the exposure of class members to direct manipulation rather than through accessor methods—and Hunt and Thomas recommend code generators and automated builds, configuration files, MVC techniques, and vigorous and proactive refactoring as ways to forestall duplication.

They also advocate tight interlacing of documentation and code (à la Knuth's Literate Programming). In much the same way, the book is constructed from interlocking elements: 70 pithy tips and eleven checklists (indexed at the back of the book), section cross-references, and sidebars. This material isn't book-designer fluff, but rather the essence of the book. For use in a course, the book offers chapter exercises; as a stepping stone to further knowledge, Thomas and Hunt annotate books and other resources in a bibliography.

The companion website for the book also links to the authors' more recent publishing and training endeavors.

Table of contents:

• Foreword
  
• Preface
  
• 1 A Pragmatic Philosophy
  
  
  
  • 1. The Cat Ate My Source Code
    
  • 2. Software Entropy
    
  • 3. Stone Soup and Boiled Frogs
    
  • 4. Good-Enough Software
    
  • 5. Your Knowledge Portfolio
    
  • 6. Communicate!
    
  
  
• 2 A Pragmatic Approach
  
  
  
  • 7. The Evils of Duplication
    
  • 8. Orthogonality
    
  • 9. Reversibility
    
  • 10. Tracer Bullets
    
  • 11. Prototypes and Post-It Notes
    
  • 12. Domain Languages
    
  • 13. Estimating
    
  
  
• 3 The Basic Tools
  
  
  
  • 14. The Power of Plain Text
    
  • 15. Shell Games
    
  • 16. Power Editing
    
  • 17. Source Code Control
    
  • 18. Debugging
    
  • 19. Text Manipulation
    
  • 20. Code Generators
    
  
  
• 4 Pragmatic Paranoia
  
  
  
  • 21. Design by Contract
    
  • 22. Dead Programs Tell No Lies
    
  • 23. Assertive Programming
    
  • 24. When to Use Exceptions
    
  • 25. How to Balance Resources
    
  
  
• 5 Bend, or Break
  
  
  
  • 26. Decoupling and the Law of Demeter
    
  • 27. Metaprogramming
    
  • 28. Temporal Coupling
    
  • 29. It's Just a View
    
  • 30. Blackboards
    
  
  
• 6 While You Are Coding
  
  
  
  • 31. Programming by Coincidence
    
  • 32. Algorithm Speed
    
  • 33. Refactoring
    
  • 34. Code That's Easy to Test
    
  • 35. Evil Wizards
    
  
  
• 7 Before the Project
  
  
  
  • 36. The Requirements Pit
    
  • 37. Solving Impossible Puzzles
    
  • 38. Not Until You're Ready
    
  • 39. The Specification Trap
    
  • 40. Circles and Arrows
    
  
  
• 8 Pragmatic Projects
  
  
  
  • 41. Pragmatic Teams
    
  • 42. Ubiquitous Automation
    
  • 43. Ruthless Testing
    
  • 44. It's All Writing
    
  • 45. Great Expectations
    
  • 46. Pride and Prejudice
    
  
  
• Appendix A: Resources
  
  
  
  • Professional Societies
    
  • Building a Library
    
  • Internet Resources
    
  • Bibliography
    
  
  
• Appendix B: Answers to Exercises
  
• Index