Book Review: Practices of an Agile Developer

This is my review of “Practices of an Agile Developer: Working in the Real World” by Venkat Subramaniam and Andy Hunt.

Content

Aside from introductory and closing chapters, each chapter of the book describes one of 45 practices that are important in achieving an Agile development environment (one reviewer suggested it be renamed, “45 Habits of Highly Effective Developers”).

Each practices includes:

  • A practice number and title, for easy reference.
  • An explicit statement of the reasons why we might resist the practice described (the Devil’s temptation)
  • A discussion that explains the rational behind the practice and how to apply it practically, typically backed up by real-world examples
  • A summary of the key message of the chapter (the Angel’s advice)
  • The emotional outcomes of following the practice (What it Feels Like). This encourages emotional buy-in.
  • Notes on how to maintain perspective (“Keeping Your Balance”)

Strengths

The language, typography and layout make it an easy read.
The division of the book into 45 practices means that:

  • You can read it in digestible chunks
  • You can dip-in to interesting chapters
  • It is a good reference book

The thing I like most about the book is the emotional awareness of the authors. They recognise that development is as much an emotional experience as it is a technical one, and that communicating good practice needs to discuss the readers’ emotional needs as well as their practical ones. This applies to both the presentation and content of each chapter. As a result, I felt good about reading this book, and I feel good about trying out the ideas presented.

Weaknesses

One thing I disliked is that some of the “practices” described in the book are much more abstract than others. For example, practice #7 (“Know When to Unlearn”) is quite abstract in that it deals with a general attitude that you should adopt towards your existing practices. In contrast, practice #6 (“Invest in Your Team”) is much more concrete, in that it deals with the specifics of how to set up”Brown Bag Sessions” with your colleges. Now, there are both advantages and disadvantages of this variation in tone. On the positive side, the variety makes for a more interesting read, and if you’re taking a pick-and-mix approach to Agile it means that you are more likely to find a practice that you can experiment with at a level appropriate to your current team. On the other hand, it makes the practices a little more difficult to introduce in a systematic way.
The biggest failing of this book is that it does little to integrate the various Agile practices. Now, these practices can adopted independently, and this book does a lot to help you explore them individually. Clearly, then, suggesting that they are reliant upon each other would have been a mistake. On the other hand, getting everything working together isn’t always easy: a little more guidance in that direction would have been very welcome.

Conclusion

I wouldn’t want this to be my only book on Agile Development: you’ll need something else to help you integrate these practices into a system. It is well written, however, and would be a good reference for someone new to Agile Development. Experienced Agile developers will find many of the practices rather basic, but might still be inspired by this book to try new things. In my view this is a 4-star book.

Best Practices: Variables

Notes from Code Complete 2: Chapter 10

Date Types

  • Know your data types (10.1)

Declaration and Naming

  • Declare all variables (turn off implicit declarations) (10.2)
  • Follow naming conventions (10.2)

Initialization

  • Initialize each variable as it’s declared (10.3)
  • Declare and define each variable close to where it’s first used (10.3)
  • Initialize working memory at the beginning of your program
  • Use the compiler setting that automatically initializes all variables
  • Initialize a class’s member data in its constructor
  • Pay special attention to counters and accumulators – ensure that they are initialized properly and, if necessary, reinitialized each time they are used
  • Check the need for reinitialization
  • Check that variables are reinitialized properly in code that’s executed repeatedly
  • Initialize named constants once; initialize variables with executable code
  • Check input parameters for validity
  • Use a memory-access checker to check for bad pointers
  • Don’t assign a value to a variable until just before the value is used
  • Use final or const when possible
  • Use named constants (avoid magic numbers)
  • Strike a conscious balance between the flexibility of late binding and the increased complexity associated with late binding

Scope

  • Ensure that variables have the smallest scope possible
  • Develop the habit of declaring and initializing all data right before it’s used
  • Localize References to Variables
  • Keep Variables “Live” for as Short a Time as Possible
  • Initialize variables used in a loop immediately before the loop rather than back at the beginning of the routine containing the loop
  • Group related statements
  • Break groups of related statements into separate routines
  • Begin with most restricted visibility, and expand the variable’s scope only if necessary

Purpose

  • Use each variable for one purpose only
  • Avoid variables with hidden meanings
  • Make sure that all declared variables are used

Persistence

  • Write code that assumes data isn’t persistent (10.5)

Release

  • Set variables to “unreasonable values” when you’re through with them (10.6)

General

  • Enable and pay attention to compiler warnings