about me about me
photography photography
software projects software projects
contact me contact me
The corner of my copy was damaged during delivery

I’m reading a lot of books on Agile at present, I figure this will help me de-bunk some of the Agile buzz on the web at the moment. I just finished reading Practices of an Agile Developer this morning.

I’ve seen an increasing amount of criticism about Agile methods, the primary response to this criticism is that those criticising are not practicing “Agile” correctly. My goal is to try and improve my own software development practices therefore I wanted a clear understanding of what “Agile” is so I can do it right from the start.

The delivery guy clearly decided to do a bit of down hill sledging with my copy – burning through one corner of the packaging and the book!

For the most part I liked the format of this book, it’s quite concise at 172 pages but this is no bad thing as what needs to be conveyed is done well with good quotes, analogies and aphorisms.

This book contains 9 chapters, each one of these are broken down into more bite sized topics. Topics begin with the shortcut method of getting the task done – one that should not be part of professional software development but still occasionally find there way in there. The section then goes on to explain how the issue should be approached, a sound bite summary from your guardian angel, what it feels like and advice on how to keep your balance when implementing the practice.

While reading through the book a many of the topics seem like common sense. I’d even say some practices mentioned in this book like keeping your code simple and writing cohesive code isn’t Agile per se but general good programming practice.

“Quick Fixes Become Quicksand”

“Damn the Torpedoes, Go Ahead”

“Put Angels on Your Shoulders”

The name of some topics smelt, to me, like the authors are trying to coin development practice patterns.

The early chapters are more people orientated than the later part of the book, after reading the first 50 pages I felt as though I’d just read how to be a good person / conscientious employee rather than anything Agile developer specific.

This isn’t a criticism probably more just a realisation that the Agile approach is one that emphasizes people, collaboration and doing The Right Thing™. The more I read on this topic, the more I get the impression that Agile isn’t as new a concept as I’d first thought but this is simply the current guise for this construction orientated methodology.

This book did enlightening me on a few terms I’ve run into before but have never taken the time to research. One in particular is “Tell, Don’t Ask”, chapter 6 explained this well.

Procedural code gets information and then makes decisions. Object-orientated code tells objects to do things.

If you want to pursue some of the practices such as User Stories or Agile estimating and planning you’ll probably need to purchase another book on those subjects rather than rely on this book alone.

Throughout this book recommended reading references are included for further insight on a topic and Appendix A provides a list of useful links if you want to read up further on subjects.

In conclusion this book accomplishes what it sets out to do, present a good overview of the Agile practices without pitching it as some sort of religious dogma that has to be followed to the word.


comments

No comments for this post.

this post's tags