Extreme Programming Explained (fwd)

[Brian Behlendorf <br...@apache.org>]

Interesting idea for a book.  Anyone looked at this yet?  Anything useful
to a project like ours?

	Brian

---------- Forwarded message ----------
Date: 21 Dec 1999 17:12:02 -0000
From: brian-slashdotnews@hyperreal.org
To: slashdotnews@hyperreal.org
Subject: Extreme Programming Explained

Link: http://slashdot.org/books/99/12/21/097256.shtml
Posted by: Hemos, on 1999-12-21 14:10:03 EDT
Dept: is-it-like-snowboarding, topic: News

   While I've been sitting on this for a little while, [1]chromatic has
   been patient. Yes, it's his review of Kent Beck's Extreme Programming
   Explained. The publisher is Addison-Wesley, and the book is for all
   those people out there who need to do programming but don't have time
   to do the engineering phase. Interesting book - click thru to read
   more.
   
   Title:Extreme Programming Explained
   author Kent Beck
   publisher Addison Wesley, 09/1999
   ISBN 0201616416
   pages 179
   rating 7/10
   summary Extreme Programming Explained explains the virtues of the
   Extreme Programmer and shows you how to develop them.
   reviewer [2]chromatic
   
  The Hook
  
   Want to write better code? How about working less overtime, getting
   along with your team better, meeting customer demands more quickly and
   accurately, spending less money, and having more fun?
   
   Extreme Programming may be for you.
   
   Be prepared to make some adjustments and sacrifices. Individual code
   ownership? Gone. Programming for the future? Slow down, cowboy.
   Working on your own? Grab a partner and dance.
   
  What's the Scoop?
  
   Extreme Programming is a way to improve software development by
   focusing on what really matters. If it will cost you $50,000 to
   implement a feature now that may not be used for two years, and it
   will cost you $55,000 to implement it in two years, hold off. If
   running test suites is good, write tests for every significant piece
   of the system. If multiple pairs of eyes make bugs shallower, program
   in pairs. If you enjoy meeting deadlines (and not working your fingers
   to the bone every night for weeks to do so), make shorter deadlines.
   
   It sounds simple, even deceptively so. It may also set your teeth on
   edge at first.
   
   Imagine that your customer has the time and the manpower to send a
   representative to sit with your programming team. He is actively
   involved in the design, writing 'stories' about how the system works
   for the end users. Every morning and afternoon, your programmers meet
   to decide which tasks to tackle, and they pair off, sharing one
   computer between them. One person codes and the other watches, and
   they switch off as necessary.
   
   With every change to the system, the previous tests are rerun until
   they work perfectly, and new tests are added to test new
   functionality. Changes are not commited until all tests run
   successfully.
   
   Releases are started early (six months, for a big programming project)
   and continue quickly after that (every couple of months). With a
   customer sitting in with the programmers, feedback can be
   instantaneous. The initial investment pays off quickly, while expenses
   are spread out over a greater period of time.
   
   With no one owning a particular section of code, and with everyone
   working with different partners from day to day, everyone should have
   a good overview of the system as a whole. This can lead to better
   programming, from less bugs to very quick refactoring. New programmers
   can also be brought in and up to speed much more quickly.
   
  What's to Like?
  
   The book is clear and readable -- even funny. Chapters are short and
   to the point. Beck uses the metaphor of driving to bring his point
   across. (Driving is not about pointing in the right direction and
   maintaining that course, it's about making slight corrections all of
   the time.)
   
   The bibliography is a great place to find some classic works
   (including books by Brooks and Knuth and even the movie 'The Princess
   Bride' -- no, really!).
   
   Extreme Programming itself has a lot of promise. Some of the
   principles (programming for today, releasing early and often, peer
   review, community code ownership) fit in pretty well with open
   source/free software. Some of the other ones would be nice to see....
   
  What Might Annoy You?
  
   It's not clear where Extreme Programming fails. To the author's
   credit, he mentions this and gives some guidelines, but the choice and
   the implementation ultimately rest with the managers and bean
   counters. There will be some resistance at first, but Beck's
   enthusiasm is infectious and his clarity of explanation might be
   enough to overcome it.
   
  The Wrapup
  
   If you're a member of or a manager of a moderate programming team, you
   ought to read this book. It will go nicely on the shelf next to "The
   Mythical-Man Month". If you're curious about new ways to look at
   programming (especially in a group), you'll want to pick it up.
   
   Purchase this book at [3]fatbrain.
   
  Table of Contents
  
    I. The Problem
         1. Risk: The Basic Problem
         2. A Development Episode
         3. Economics of Software Development
         4. Four Variables
         5. Cost of Change
         6. Learning to Drive
         7. Four Values
         8. Basic Principles
         9. Back to Basics
   II. The Solution
        10. Quick Overview
        11. How Could This Work?
        12. Management Strategy
        13. Facilities Strategy
        14. Splitting Business and Technical Responsibility
        15. Planning Strategy
        16. Development Strategy
        17. Design Strategy
        18. Testing Strategy
   III. Implementing XP
        19. Adopting XP
        20. Retrofitting XP
        21. Lifecycle of an Ideal XP Project
        22. Roles for People
        23. 20-80 Rule
        24. What Makes XP Hard
        25. When You Shouldn't Try XP
        26. XP at Work
        27. Conclusion

References

   1. http://snafu.wgz.org/chromatic
   2. http://snafu.wgz.org/chromatic
   3. http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201616416&from=MJF138