Blog Archive for / reviews /

Review of Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process by Scott Ambler

Wednesday, 08 February 2006

This is a reasonably long book, at nearly 400 pages; it would be even longer if it wasn't for the excessively large number of words per page. I found this book hard to read, in part due to the layout, and in part due to Scott's writing style. Though he is a stout member of the Agile camp, Scott clearly also believes in the benefit of repetition to get his message across; there is many a repeated phrase or sentence, and there is at least one whole paragraph repeated word-for-word. All this detracts from the book, which is unfortunate since Scott has a lot of good things to say.

The book is divided into 5 parts. The first two parts cover the principles you should work to and practices you should be doing to say that you are doing Agile Modeling as Scott defines it. The values of Agile Modeling are the four values of eXtreme Programming, plus a fifth (Humility), and the principles and practices are then derived from applying these values to a modelling perspective. For example, the value of Courage leads one to Discard Temporary Models, and the values of Humility and Communication lead one to realise that Everyone Can Learn From Everyone Else, and that you should Model With Others. This description of the principles and practices forms the real meat of the book. Most (perhaps all) of what Scott says here is sensible advice which should be followed by anyone pursuing an Agile approach to software development.

The remaining parts describe the how Agile Modeling fits into XP and the Universal Process, with a discussion on introducing Agile Modeling into your process. This also includes a discussion of when Agile Modeling is *not* a good fit, as well as a check list of things you must be doing to say you are Agile Modeling, and a list of things which you must not be doing if you want to say you are Agile Modeling. The book finishes off with an appendix listing a host of modelling techniques to consider when the need arises; Scott is quite clear that you need to Apply the Right Artifact, and having a wide range to choose from makes this easier since you are not stretching a model beyond what it can easily cover.

If you are interested in modelling, and want to know how it fits into Agile projects, or you are looking to make your current process more Agile by reducing unnecessary modelling work, then this book is well worth a read; I just wish it was easier to read.

Recommended.

Buy this book

At Amazon.co.uk
At Amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Review of Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects by Andreas Rueping

Wednesday, 08 February 2006

The title of this book is "Agile Documentation", but almost everything it says is applicable to documentation for any project, whatever methodology is used. Indeed, much of what is said is common sense if you think about it — but how often does anyone really think about it? Reading this book forces the issue, and hopefully encourages one to think about the purpose, readership and content of documentation a bit more in the future. However, some of the content is particularly important when trying to use an Agile development method, since it contributes to reducing the effort that is wasted on unused or unnecessary (or even unusable) documentation, whilst ensuring that the documentation that is produced is both necessary and sufficient for the project's needs.

The subtitle is "A pattern guide for producing lightweight doucments for software projects", which is quite apt. Essentially, the book consists of a set of patterns, divided into 5 groups, each of which describes a particular problem associated with documentation, and some discussion of the solutions. The key points are summarised in what the author calls "thumbnails" — a couple of sentences which appear in bold type in the pattern description, and which are then repeated in the "thumbnails" section at the back of the book. These enable you to browse through the book, reading each pattern heading and the corresponding thumbnail to get an overview of the pattern and determine whether it is applicable for your current situation, or jog your memory.

The patterns are not just presented on their own, they are backed up by experience reports from a number of projects that the author has been involved with. These are used both within the pattern descriptions, and in a separate section at the end of each chapter. They are not all positive, and are used to highlight the dangers of not following the patterns from the book, as well as the benefits of doing so. Overall, they give the advice a place of reference, and are the source of numerous examples.

One slight issue I had with the book was the number of typos, which was particularly unexpected given the subject matter. However, this did not detract too significantly from my overall impression: Highly Recommended

Buy this book

At Amazon.co.uk
At Amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Review of Lean Software Development: An Agile Toolkit, by Mary Poppendieck and Tom Poppendieck

Wednesday, 01 February 2006

If you're not convinced that Agile Software Development practices are at least worth investigating further after you've read this book, then you'll never be convinced. It is a well-written guide to the ideas behind Agile thinking, with plenty of references to other sources (the bibliography is 8 pages long); both those showing the benefits of Lean thinking in software and manufacturing, and the "original" sources for various techniques and methodologies. The interested reader therefore has plenty of material for ideas on where to go next, having accepted Agile practices as effective development practices.

The book divides lean thinking into 7 key principles, with 22 "tools" to help you adapt agile practices to your workplace. It also features a "try it out" section at the end of each chapter taking you through some simple steps that demonstrate how the particular techniques discussed can be applied to improve your software development process.

Some of these principles are obvious at first glance — "Eliminate Waste" for example — but this simplicity hides profound insight; in this case, the insight is that much of the "work products" of traditional software development processes are in fact waste, produced purely so the developer can "tick the box" and move onto the next task. Not only that, but the very process can itself generate waste — having analysts produce specs from customer requirements, which designers then turn into a high level design for coders to turn into software is very wasteful, because knowledge is lost at every stage; the very act of writing something down means that the understanding and background knowledge held by the author is lost, either permanently, or until the reader has acquired it for himself.

This book is aimed at project managers and lead developers looking for ways to improve their software development process, but I would recommend it to anyone who is serious about producing quality software. Whilst many agile practices require management buy-in (and if you can get your manager to read this book, it will probably help), others can be implemented by developers as part of almost any process.

Buy this book

At amazon.co.uk
At amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Review of C++ Coding Standards: 101 Rules, Guidelines and Best Practices, by Herb Sutter, Andrei Alexandrescu

Wednesday, 01 February 2006

The key points from the book are neatly summarised in the 12 page "Summary of Summaries" at the back of the book. This lists all 101 guidelines, with both their title and summary; the primary reason for reading the main body of the book is to understand the background and reasoning behind the guidelines, as well as any exceptions. These guidelines are not casually thrown together; they are well researched, with extensive references. It is also worth reading the introductory text to each section, as this pulls the guidelines from the section together; a nice touch from the authors is the selection of a "most valuable Item" from each section, one which you really really ought to follow.

In contrast with other books from Addison Wesley, such as Effective STL, which have a much easier-to-read layout, but in common with the other books in the C++ In Depth series, the text is slightly too small, and the margins slightly too narrow, so there is too much text on a page. This, combined with the high density of technical content, makes it hard to read cover to cover in one go. There are also a couple of errors; though nothing major, they do detract from the authority of the book, given the nature of the content.

In the preface, the authors state that they intended each item to be short, non-controversial, authoritative, and something that needs saying, and I believe they have achieved that. In any set of coding standards I usually find something that I disagree with, but there was not a single item that grated on me here. I agree with the authors that this book is something you should reference from your own coding standards.

Highly Recommended.

Buy this book

At Amazon.co.uk
At Amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

Review of Test Driven Development - A Practical Guide, by Dave Astels

Wednesday, 01 February 2006

This book is subtitle "A Practical Guide", and it is definitely that. It includes an overview of many of the tools available to assist you in using Test Driven Development (TDD), along with detailed descriptions of how TDD works in practice. The bulk of the book is taken up with working through a complete project from start to finish using TDD. This demonstrates many of the techniques in action, and gives examples of how to test different types of behaviour, including the GUI, which is notoriously hard to test. The book also includes appendices giving an overview of eXtreme Programming and Agile Modelling.

Most of the book uses Java as the target language, and it does appear that the majority of tools available are for Java. However, that does not mean that the techniques discussed are not applicable to other languages; there are chapters in this book dedicated to the use of the "xUnit" testing framework for various languages "x" — such as C++, Python, and Visual Basic.

The main thrust of TDD is that you write tests for the expected behaviour of the production code before you write the code, and that you don't add new code to the system except in response to a failing test. This takes some getting used to, but the key benefit is that you get a high-coverage automated test suite which automatically tells you if you break something when you make a modification.

As programmers, we all know that automated unit tests are a Good Thing, but writing tests after the fact is difficult, and seems like a chore since we already "know" the code works. TDD is not like that. I've been trying it on my latest project, and I am now "test infected" — I'd rather work this way than how I worked before. Applying the techniques discussed in the book to C++ was relatively straightforward; with the help of a few editor macros, adding a new test takes just two key presses, and I've managed to add the automated tests to the build script, so they appear as compile errors in the IDE.

I would recommend this book to all developers, especially those who find writing tests tedious or unnecessary, and those who wish they had a better set of tests when modifying code. Though TDD is one of the key techniques used in Agile methodologies, it can be used under any methodology, since it just replaces the developer tests that most developers would like to have anyway (but probably don't).

Highly Recommended.

Buy this book

At Amazon.co.uk
At Amazon.com

Posted by Anthony Williams
[/ reviews /] permanent link
Stumble It! | Submit to Reddit | Submit to DZone

Comment on this post

If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.

More recent entries

Design and Content Copyright © 2005-2024 Just Software Solutions Ltd. All rights reserved. | Privacy Policy