I’m a bit behind schedule with regard to my book reviewing commitment but I’ve at least been able to finish off a couple of the volumes I committed to and now I am ready to share some views on Practical API Design by Jaroslav Tulach.

This book is a rather personal presentation by Tulach – the author is constantly relating to his personal experiences as developer/architect of the Netbeans platform (on which the famous IDE is built).  Tulach doesn’t refrain from lengthy, and sometimes rather esoteric, argumentations and analogies even going so far as to comparing API design with astronomical observations.

There are some golden nuggets here and there, some techniques and observations that were new to me, but in general I think there is too little meat and too much padding. The book is perhaps of most interest to designers of very long living API:s with a large number of disparate users, for lowly general Java devs like me there are far more rewarding reads among the books that have recently been published in the field of software engineering. A suggestion would be the extremely “meaty” Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin (a.k.a Uncle Bob).

The Scrum course I recently attended didn’t only net me a Certified Scrum Master diploma – a copy of Ken Schwaber’s Agile Project Management With Scrum was also handed out. Overall I found the most recent addition to my software engineering book shelf quite accessible, of modest length (about 150 pages) and divided into logical chapters that don’t need to be consumed in succession.

The main bulk of the book is is a large number of case studies focusing different aspects of the Scrum process, such as the role of the Product Owner, Scrum Master etc. Every case study is followed by a short summary outlining the lesson Schwaber think can be learned from it. I think this approach is quite nice and makes for an entertaining read.

However, authored in 2003 as the book is some passages have a somewhat dated feel. Also, Scrum sprint length is consistently assumed to be 30 days with no convincing argument presented on why this would be the ideal iteration length.