Ten for the Holidays
It's been a good year for programming books. Well, not for sales--they
dropped again this year, as even more developers switched from dead trees
to Google--but I can't remember ever having as many good books on the
"how" and "why" of programming land on my desk. So, for those of you who
still haven't finished your seasonal shopping, here are ten (plus a few)
of my favorites, both new and old.
0. Joel on Software
If you're involved in the software industry in any capacity--developer,
manager, cheerleader on the sidelines--Spolsky's weblog is a must-read.
His observations on hiring programmers, measuring how well a development
team is doing its job, the API wars, and other topics are always
entertaining and informative. This book (which is a collection of his
online essays, updated and cross-linked) ranges from the specific to the
general and back again, tossing out pithy observations on the
commoditization of the operating system, why you need to hire more
testers, and why NIH (the not-invented-here syndrome) isn't necessarily a
bad thing. Most of this material is still available on the Web, but having
it in one place, edited, with an index, is probably the best 25
dollars you'll spend this year.
Joel Spolsky: Joel on Software. APress, 2004, 1590593898, 362 pages.
1. Coder to Developer
The subtitle of Coder to Developer is "Tools and Strategies for
Delivering Your Software," and that's exactly what it's about. Project
planning, source code control, unit testing, logging, and build management
are all there; importantly, so are newer topics, like building plugins for
your IDE, code generation, and things you can do to protect your
intellectual property. Everything is clearly explained, and illustrated
with well-chosen examples. While the focus is definitely on .NET,
Gunderloy covers a wide range of other technologies, both proprietary and
open source. I'm already using two new tools based on references from this
book, and plan to make the chapter on "Working with Small Teams" required
reading for my students.
Mike Gunderloy: Coder to Developer. Sybex, 2004, 078214327X, 297 pages.
If you're going to read C2D, you should also read The Pragmatic Programmer. (Fair notice: I'm currently writing a book for Andy and Dave myself.) Everyone I give this book to comes back and says, "I wish I'd had a course about this stuff at college." PP is about those things that make up the difference between typing in code that compiles, and writing software that reliably does what it's supposed to. Topics range from gathering requirements through design to the mechanics of coding, testing, and delivering a finished product. The second section, for example, covers
"The Evils of Duplication," "Orthogonality," "Reversibility," "Tracer
Bullets," "Prototypes and Post-It Notes," and "Domain Languages," and
illuminates each with plenty of examples and short exercises. I don't
agree with everything they say, but it's all thought-provoking. If you
only read one book from this list, do your customers a favor, and make it
one of these two.
Andrew Hunt and Dave Thomas: The Pragmatic Programmer.
Addison-Wesley, 1999, 020161622X, 352 pages.
2. Facts and Fallacies of Software Engineering
Glass presents 55 facts (some a little fuzzier than anything I'd
call a "fact," but never mind), and ten fallacies under headings such as
"Management," "Reuse," and "Testing." What's more, he also cites some of
the evidence we have to back up these statements. Some of what he says is
well-known: good programmers are up to N times better than bad ones (his
value for N is 28), reusable components are three times harder to build
than non-reusable ones, and so on.
Other facts aren't part of the zeitgeist, though they should be. For
example, most of us know that maintenance consumes 40 to 80 percent of software
costs, but did you know that roughly 60 percent of that is enhancements, rather
than bug fixes? Or that if more than 20 to 25 percent of a component has to be
modified, it is more efficient to rewrite it from scratch? If nothing
else, this book is a better way to start thinking about our profession
than the "everybody knows" factoids you're likely to soak up at coffee
Robert L. Glass: Facts and Fallacies of Software Engineering.
Addison-Wesley, 2003, 0321117425, 195 pages.
3. How Buildings Learn
This thought-provoking book starts with the observation that most
architects spend their time reworking or extending existing buildings,
rather than creating new ones from scratch. By presenting examples ranging
from the MIT Media Lab to a one-room extension to a house, Brand
encourages us to see patterns in the way buildings change (or, to adopt
Brand's metaphor, the way buildings learn from their environment and from
use). He uses those insights to argue that since buildings are always
going to be modified, they should be designed to accommodate unanticipated
I've included this book in a list for programmers for two reasons. The
first is that everything Brand says about buildings is true of software as
well; he just explains it better than most authors of programming books.
The second is that How Buildings Learn is beautifully produced: the
photographs, sketches, typography, and layout are a sweet treat for
Stewart Brand: How Buildings Learn: What Happens After They're Built.
Penguin USA, 1995, 0140139966, 256 pages.
4. Working Effectively with Legacy Code
This is a great book, but one that probably won't resonate with you until
you've spent at least a couple of years trying to bash other people's old
code into shape. Feathers defines legacy code as code that doesn't have
tests. As he says, most programmers spend most of their time fixing bugs,
porting to new platforms, adding new features--in short, changing
existing code. If that code is exercised by unit tests, then changes can
be made quickly and safely. If it isn't, they can't, so your first
priority should be to get the code you're changing under test.
Simple, right? Except that most of us don't do it, or don't do it well,
because we've never been shown how to do it systematically. Want to know
three different ways to inject a test into a C++ class without changing
the code, which classes or methods to focus testing on, or how to break
inter-class dependencies in Java so that you can test one module without
having to configure the entire application? It's all here.
Michael C. Feathers: Working Effectively with Legacy Code.
Prentice-Hall PTR, 2005, 0131177052, 434 pages.
5. Unlocking the Clubhouse
As a rule, women do not choose to go into computer science; many of those
who do later choose to pursue something else instead. This book looks at
why this is, and at what we can do about it. Its first six chapters
describe the many ways we are conditioned to believe that computers are
"boys' things." Later on, the "who needs a social life?" atmosphere of
undergraduate computer labs drives many women away (and many men, too). As
the authors point out, almost three quarters of students of both genders
believe that they do not fit the stereotype of a computer science
The last two chapters describe what the authors have done to remedy the
situation at Carnegie-Mellon. By being conscious of the many things that
turn women away from computing, and by viewing computer science from different
angles, we can attract a broader cross-section of society, which can only
make our discipline a better place to be.
Jane Margolis and Allan Fisher: Unlocking the Clubhouse. MIT Press,
2003, 0262632691, 182 pages.
6. How Tomcat Works
You have no idea how much I wish there were more books like this one.
How Tomcat Works is a detailed, step-by-step explanation of how the
world's most popular Java servlet container works. Kurniawan and Deck
start with a naive web server that only handles static HTML pages, then
build up to a full-blown servlet container one feature at a time. Each
time they add code, they explain what it does, and why it's needed. There
were paragraphs I had to read several times to understand, but that's
OK--the things they're trying to describe are complex and subtle.
Budi Kurniawan and Paul Deck: How Tomcat Works. BrainySoftware.com,
2004, 097521280X, 450 pages.
7. Malware: Fighting Malicious Code
This thick brick of a book is a survey of harmful software, from viruses
and worms through Trojan horses, root kits, and even malicious microcode.
Each threat is described and analyzed in detail, and the author gives
plenty of examples to show exactly how the attack works, and how to block
(or at least detect) it. The writing is straightforward, and the case
studies in Chapter 10 are funny without being too cute. It's one of the
best practical books on software security I've come across so far, and
also the one that I think is most widely useful.
Ed Skoudis: Malware: Fighting Malicious Code. Prentice-Hall, 2004,
0131014056, 647 pages.
8. GUI Bloopers
Most books on GUI design are long on well-meaning aesthetic principles,
but short on examples of what it means to put those principles into
practice. In contrast, GUI Bloopers presents one example after another,
all drawn from widely used desktop applications: "What's wrong with this
dialog? What should its creators have done instead? And, most importantly,
why?" The net effect is to teach all of the same principles that other
books try to, but in a way you can immediately apply.
The sequel, Web Bloopers, applies the same approach to web sites. Each
section puts a name to a common mistake, gives several real-world examples
of its occurrence, and then explain what the site's designers should have
done instead. As you read the book, you can almost hear Johnson patiently
saying, "OK, let's see ... You've repeated information here and here, and
these links all lead back to the same place. Perhaps we could reorganize
it like this ..." Sure, it's all common sense, but thirty seconds on the
Web will show you how uncommon good design sense actually is.
Jeff Johnson: GUI Bloopers. Morgan Kaufmann, 2000, 1558605827, 2000,
9. Java Open Source Programming
The biggest change in programming in the past two or three years hasn't
been .NET. Instead, it's been the emergence of a "New Standard Model" of
programming to replace the venerable combination of C, Emacs, Make, Unix
command-line tools like
grep, CVS, and character streams. Its
main elements are:
- Eclipse and its many plugins
- Ant (for building), JUnit (for testing), and Subversion (for version
- Tomcat (as a universal deployment engine)
- Reflection (for making systems extensible)
- XML as a universal storage format
- Test-driven development and systematic refactoring
JOSP covers these topics, and many more; it also shows how they all fit
together. Want to know how an experienced developer figures out how to
manage object lifecycles and dependencies? That's Chapter 14. Look and
feel? See Chapter 17, and so on. Best of all, the authors put as much
emphasis on testing as developers know in their hearts they ought to.
Joe Walnes, Ara Abrahamian, Mike Cannon-Brookes, and Pat Lightbody: Java Open Source Programming. Wiley, 2004, 0471463620, 459 pages.
If JOSP isn't to your liking, you may prefer one of these:
- Eric Burke and Brian Coyner: Java Extreme Programming Cookbook. O'Reilly Media, 2004, 0596003870, 352 pages.
- Richard Hightower and Nicholas Lesieck: Java Tools for Extreme Programming. Wiley, 2001, 047120708X, 544 pages.
- Richard Hightower et al: Professional Java Tools for Extreme Programming. Wrox, 2004, 0764556177, 768 pages.
|width="1" height="1" border="0" alt=" " />|