A couple of weeks ago I was in Southampton and the Borders there was having a sale on all computer books… so I picked up “Practices of an Agile Developer” by Venkat Subramaniam and Andy Hunt. Before I discuss the book I am going to go in to a little background.
One of my annual commitments I made back in October 2008 for 2009 was to learn about Agile practices… partially motivated by already being enrolled in a course that I’m taking next week. I have been interested in these practices for quite some time though so this book is not my first exposure to agile thinking. Before I left Ds Ltd for Lionhead Studios just over two years ago I had already co-authored an internal standards and practices document that encouraged various agile practices.
During university and the first year as a full time developer I was way more interested in learning some C++ tricks and a then newfangled language called C# that the management were for whatever reason excited about ;). It is very easy as a developer to neglect the soft skills when there are cool new programming things to learn.
At university we were taught things like the Waterfall model, PRINCE and ISO 9000 accreditation – and whereas these things are important they do create a lot of paperwork. ISO 9000 for example can fantastically document a horrific failure. Things like “requests for change” that had to be signed off by more than one person are there to chain a customer to their original requirements. GANNT charts created by MS Project used to make pretty diagrams that end up being a work of fiction because of unexpected bumps along the way. It felt like setting up ways to assign blame for what goes wrong rather than concentrating on working together for a solution. You get requirements, develop the software for a while, then hand it back. It was contract negotiation over customer collaboration. Knowledge of these management principles is important so that you can make informed choices and discussions later on – but you will find every company has their own twist on the above anyway (the twist at university was everything was so literal and to the letter).
Other soft skills taught at university like uml, data flow diagramming, crc cards, database modelling are immediately useful in the real word for a graduate developer. Sometimes these things are taught in a way that divorces them from the code too much; design everything first, code everything using the design later. This again isn’t the best way in practice (though probably a good way to create an assignment marking scheme). While it is important to design up front, going in to too much depth lends itself to over-engineering. For example, classes created where properties would do, usage of patterns adding needless complexity to a solution, another layer of abstraction to solve a problem, “is-a” being taken too literally when applied to inheritance in class designs, etc.
So what better way to stop yourself wasting time and creating software that doesn’t please your users (or even get finished) than to read about other people’s experience first and not make the same mistakes?
“Practices of an Agile Developer” is a decent book that is all about how to be a positive influence on those around you no matter the position you hold. It holds extra value for managers, producers and those that are in a position to lead from the top of course – but there are many things you can do on a personal level suggested in the book. Committing to some of the things it suggests has the potential to make you more effective, and perhaps your work day more pleasant.
The book itself is quite short, but that is reflected in the price and concise style. A chapter concentrates on a specific area of agility skills that is broken in to sections describing individual techniques. Each technique is documented with a clear structure – identify a good and bad practice (represented by an angel and devil next to a box-out), then a personal experience from the authors and to finish off clear bulleted list of things to do. The solutions at the end are particularly interesting in that they are always clear that taking the suggested practice too far can often be as harmful as not doing it at all. Each technique also has “what it feels like” heading which describes the agility pay off when it has been applied in a balanced way.
The authors balanced, non-fanatical standpoint is much easier to digest than other books I have come across. Ruby is mentioned a few times in a very rosy light, but considering the authors have close ties to the language you can let that pass. The book does often refer to other books in the pragmatic programmers series which almost seems like advertising – though by not repeating other books it does mean the book keeps a tight communication and personal practice focus.
The first book in the pragmatic programmer series I brought was “Ship it!: A Practical Guide to Successful Software Projects” back in 2005 – which concentrates more on the practical detail of setting up a good production environment and development pipeline than team and customer relationships. It is another insightful book full of practical examples of how to get things done – I have not read it front-to-back for a while but I may review it in the future.
“Practices of an Agile Developer” is a pragmatic look at practices that have been proven to work in the field. It is a management book written for developers by developers. Primarily I would recommend the book to students that aren’t quite getting the connection between modelling, code, and time management. As for anyone else a bit more experienced it is a good introduction to agile practices that isn’t terribly preachy – and does not smell of Power Point.
 |
“Practices of an Agile Developer” by Venkat Subramaniam and Andy Hunt |
 |
“Ship it!: A Practical Guide to Successful Software Projects” by Jared Richardson and William Gwaltney Buy from amazon.com Buy from amazon.co.uk |
P.S. Anyone have any requests for a subject you would like me to write about? Anything sensible that doesn’t break my NDA will be considered 🙂
Tags: agile, book review, game industry, management, software development
Paul Evans 
2009/02/15 at 20:28
Good post. I, too, want to improve my skills at software development. I see the book is only 176 pages, so it is short enough to read over a couple of nights. I’ll put it on my wishlist. I have a friend who raves that the best style of programming is the one that is most agile.