Ten for the Holidays Blog

Version 2

    {cs.r.title}



              
                                    

    Contents
    0. Joel on Software
    1. Coder to Developer
    2. Facts and Fallacies of Software Engineering
    3. How Buildings Learn
    4. Working Effectively with Legacy Code
    5. Unlocking the Clubhouse
    6. How Tomcat Works
    7. Malware: Fighting Malicious Code
    8. GUI Bloopers
    9. Java Open Source Programming

    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 toN 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 time.

    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 change.

    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 CRT-strained eyes.

    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 student.

    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 Blooperspresents 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, 559 pages.

    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 catand grep, CVS, and character streams. Its main elements are:

    • Java
    • Eclipse and its many plugins
    • Ant (for building), JUnit (for testing), and Subversion (for version control)
    • 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:

      
    http://today.java.net/im/a.gif