Title: The Pragmatic Programmer, from Journeyman to Master Author: Andrew Hunt and David Longman Publisher: Addison-Wesley Longman, 2000 Pages: 352 ISBN: 0-201-61622-x Price:: $34.95 Introduction
Andrew Hunt and David Thomas have written a book filled with practical advice for programmers (and others). They hit their goal of helping people become better programmers. Their book will also help people who don't program much anymore, but who work in technical documentation and management.
The primary audience is people who want to become more effective and productive programmers. There is material here for students, programmers at all levels of experience and expertise, and (surprisingly) technical writers. This book contains material that is especially for programmers who have always used an IDE (Integrated Development Environment) and have not used an old fashioned shell (Unix or DOS command line).
The theme of the text is using basic tools that automate work and prevent duplication of effort and information. Basic tools include simple shells, ASCII files, and lots of tools that are free on the Internet. Automating tasks improves consistency and saves time. "Don't repeat yourself" (the DRY principle) reduces work and mistakes.
Contents
The book contains eight independent chapters that can be read in any order. Each section of each chapter has cross references to other sections of the book that discuss related topics. This makes it easy to skip around and learn as you wish.
The chapters include
(1) A Pragmatic Philosophy,
(2) A Pragmatic Approach,
(3) Basic Tools,
(4) Pragmatic Paranoia,
(5) Bend or Break,
(6) While You Were Coding,
(7) Before the Project, and
(8) Pragmatic Projects.One appendix contains refernces to a variety of resources ranging from professional societies to valuable but free tools on the web.
The chapter on Pragmatic Philosophy looks at the attitude of a pragmatic programmer. Pragmatic programmers should take responsibility for their work. One attitude is to repair "broken windows" now. Broken windows refer to things that are not quite right in a piece of software. The longer these faults lie unattended, the harder it is to remedy them and the more people start to accept poor quality as the norm. Pragmatic programmers should also maintain their technical knowledge by always learning and applying what they learn. Too often, we programmers (and former programmers) go on automatic pilot and do what we've always done. We don't learn and apply new lessons. Finally, the authors emphasize the value of taking the time and trouble to communicate well in both the spoken and written word.
The chapter on Pragmatic Approach includes tips that apply to all levels of programming. The authors here introduce principles that reduce work and increase productivity. First, the DRY principle — don't repeat yourself. The idea is to write information once in one place; everything else points to that one place. This makes it more efficient to enter the information (just once) and reduces errors as changing the information requires only one change.
Along with this is advice to be "orthogonal," or not to overlap anything. This carries with it the idea of keeping yourself and your software reversible, flexible, and adaptable. The authors urge creating an architecture that allows us to reverse our decisions. Suppose we decide to use a commercial database in our application. We should put a shell or interface around it. If we later feel that writing our own database functions is better, the wrapper allows us to reverse our decision without having to change the entire application.
Another idea is to use specific languages for specific situations. Special languages such as Perl, AWK, troff, and others work well in special situations. Pragmatic programmers need to know about and use these languages appropriately. This also includes creating simple languages or formatting commands that automate repetitive tasks.
The chapter on Basic Tools discusses simple, inexpensive, and powerful tools. This chapter is especially important to programmers who have used only IDEs. IDEs are easy to learn, but aren't usually programmable and hence don't allow automation of tasks. The tools recommended by the authors include plain text (this format outlives all commercial tools), shells (Unix and DOS), editors (emacs and vi), source code controllers (SCCS and RCS), text manipulators (Perl), and code generators (LaTeX and troff). If the names of these tools are unfamiliar, buy this book just for this chapter. These tools require time and energy to learn, but the time they save far outweighs the investment required.
The chapter on Pragmatic Paranoia is about living with mistakes. We all make mistakes, and the first thing to do is accept this and work through it. This chapter includes a long section on design by contract. This technique reduces errors and confines errors that get through. The authors also advise that "dead programs tell no lies." A program should quit as close to a run-time error as possible. When a program enters a wrong state, all processing thereafter is invalid. The invalid data can mislead people trying to learn what went wrong, so eliminate it by stopping the program as soon as possible.
The chapter on Bend Or Break emphasizes that the world will change and the we should be flexible and ready for the change. The biggest technique is to use loosely coupled modules of code. This goes back to the DRY principle and orthogonality ideas of Chapter 2. Loosely coupled or loosely related modules are easier to change without introducing errors. Along with decoupling, the pragmatic programmer should code for the general case and place what might change (the specifics) outside the compiled code. The specifics should be kept in a text file, one that can be read easily by any number of tools. The authors also discuss services and blackboard ideas as flexible means of communication among programs.
The chapter on While You Are Coding emphasizes thinking programmers. There are many people in the software field who feel that all the thinking is performed by senior people who analyze problems, design solutions, and pass the designs to programmers. The programmers, so the thought goes, mechanically write the code. The authors disagree and emphasize thinking, planning, and coding deliberately. They discuss studying algorithm complexity and refactoring (doing code over again better). They also emphasize writing code that is easier to test. They close with warnings about code generators. Programmers must study and understand the code created by code wizards (GUI tools as an example).
The chapter on Before The Project takes several perspectives on requirements. We need to dig for requirements; they don't lie on the surface for easy gathering. Always look to solve a business problem. The authors stress the distinctions among policy, requirements, and implementation. For example, "employee records may be viewed only by autorized personnel" is a requirement. This year's policy is "direct supervisors are authorized," while next year's may authorize several other people.
When programmers understand the requirements and how policies are likely to change each year, their implementation will allow for an easily changed list of authorized personnel. We all need to avoid the specification trap. This relates back to mechanical programming, where some people believe they can write specifications and throw them over the cubicle partition to a programmer. The authors strongly encourage the specification writer to work with the programmer all through the implementation.
The chapter on Pragmatic Projects ties pragmatic programmers together into pragmatic teams. Such teams produce quality via clean communication and responsibilities. The authors urge ubiquitous automation — using tools (some created by the team) to automate everything. This brings consistency and reduces errors. Testing should be pursued ruthlessly, and automated testing should be the norm. Documentation is a critical part of communication among team members. This goes back to the DRY principle once again. Use tools so that documentation is written once (preferably in the code) and the tools extract them and place them in web pages, paper documents, etc. The authors end with "sign your work." Everyone should have the pride and professionalism to put their names on their products.
Comments
This is a good book. It is a bit repetitious, but that is to be expected of a book with independent chapters and cross references. The topics are disjointed, which makes it difficult to pull together the main ideas. It would have been better had the authors summarized their themes.
The book is written well and easy to read. The authors break out their main points as 70 tips. It is easy to flip through the pages and find the tips. A pullout reference card of these tips and good checklists are included in the back.
Hunt and Thomas make you think about what you do and how you do it. The experiences they describe are all too familiar to programmers. They relate how we are sometimes impractical and inefficent in our jobs. I don't program much anymore; I work with documentation and management. The book made me reexamine how I was doing large parts of my job. This book has caused me to change the way I do things at work and in personal study; it made a difference to me. I suppose that is the strongest compliment you can give to a book.
If you program, read this book. If you write documentation for software, also read this book. If you work with documents, read this and apply the lessons.
Dwayne Phillips has worked as a software and systems engineer for the US Government since 1980. He has a Ph.D. in Electrical Engineering from Louisiana State University. In addition to writing about image processing for C/C++ Users Journal, he has written The Software Project Manager's Handbook, Principles that Work at Work, published by the IEEE Computer Society.