Extreme Programming Explained
by Kent Beck
Addison-Wesley
(190 pages)
Keyword(s): Nonfiction, Programming
Dates read: March 27-28, 2003,
Rating:
Every year or so, I get an urge to read some computer programming books and see if I can jolt myself out my current set of habits. Extreme Programming (XP) has been a big buzzword over the last few years. I had some vague ideas about what XP was (pair programming, writing tests first), but I never really gave it much thought.
The environment that I program in does not lend itself to software development practices involving lots of detailed planning. I work alone or in a small group, with ever-changing program requirements, and my deliverables are working prototype code and high-level documentation. So, the "embrace change" part of this book's title got my attention. However, this treatise on XP is not going to help me much. I'm convinced of the necessity of automated unit and functional testing, and I know that I need an approach that can react well to changing requirements, but I'm not convinced by the author's arguments in favor of XP as a solution. I'm also not that impressed with his facile writing style.
Test Driven Development
by Kent Beck
Adison-Wesley
(240 pages)
Keyword(s): Nonfiction, Programming
Dates read: March 28-30, 2003,
Rating:
Another disappointing software book. The concept of Test Driven Development is solid: use unit tests to drive the development of your code. Like in Extreme Programming, Kent Beck's writing style is facile, to the point of almost complete superficiality. The first half of the book describes — in overwraught detail — the development of a trivial example of code, one that any half-decent programmer could design and code in an hour. It appeared that the second major section would describe how to use xUnit (specifically PyUnit) to build test suites for code, but instead it is a pedantic exercise in building a superficial version of PyUnit, written with lousy Python programming style.
Reading this book was not, however, a complete waste of time. By spending time thinking about using tests to drive development, I've arrived at my own conclusions about what techniques to try. I can't, however, recommend this book to anyone else.


Recent entries