The Pragmatic Programmer - book review

And Christmas came... Somehow it always comes as a small surprise even though the 24. of December is a well defined, hardcoded constant in all calendars available here in Denmark.

I have spent the hours from approximately 10pm to 11pm for the last week or so reading a book authored by Andrew Hunt and David Thomas. The book is named The Pragmatic Programmer and in short it hails a pragmatic approach to developing software and offers a walkthrough to the various concepts and tools which can help individuals and teams adapt this approach.

I had no idea what the book was about - it was handed to me by one of my fellow collegues just before departing the office for Christmas leave. I had the choice between this book and another labelled "Pragmatic source control"... I know myself well enough to know that if I read a book which excels in detailed descriptions of setting up servers and programs I will eventually get rid of it in about 2 or 3 chapters and go on to something more interesting. Writing about the YAGNI principle on my blog, for instance ;o)

The choice was easy to make - I went for Pragmatic Programmer. After having read it I can tell you that it sure does deliver much of what is promised in the foreword. I had the feeling that the book and it's foreword was a paradox within itself because the foreword describes the content of the book as being close to a silverbullet towards developing software the "right" way while the authors make quite a big point out of clarifying that there is no "right" way of doing things and that every bit of software ever written is not even close to being perfect...

However - at the end of the day these are only my personal views and they should not in any way blur the fact that this is indeed a great book to read for anyone working with software development. It aims primarely at people actually coding the software but there are a lot of views and golden tips hidden within which should be considered by more parties in a software project than just the guys coding. An example is a story on how requirements gathering should be approached. The fact is that software requirements are not something you gather - they are something hidden which you dig for. I love this way of describing complex social behaviour in simple terms... Another great metaphore is that developing software should be compared to founding and maintaining a garden. Both enviroments are highly organic and both enviroments depend higly on external factors. Both enviroments are not "done" when you have finished working on them - both enviroments can decay and you will have to pay attention to maintainenance to ensure the state of your enviroment. Both enviroments require tools and educationed staff and the right tools shortens the maintenance time required. I will remember this metaphore forever because it is something everyone owning a house with even the smallest garden can relate to. This metaphore and others like it are the strongest part of the book because it enables the software engineers on a project to communicate needs and requirements to non-technical staff.

A few othe issues worth of mentioning: There is a comprehensive list of tools mentioned and the book does try to embrace both the single developer and software projects within the pragmatic paradigm. I feel that the part of the book about "Pragmatic teams" and similar chapters do violate the Don't Repeat Yourself (DRY) principle also described in the book. If you follow the principles and tips you have already read you can easily deduce yourself towards the issues described in the Pragmatic Team chapter. An example is that quality is described in the first chapters using the Broken Window metaphor - the conclusion is that you should always fight beginning software rot. You read on and in the final chapters about Pragmatic Teams you run into terms such as "Quality is a team issue" which is true - but if you have earlier read that software decay is something to fight proactively during review and refactoring you have already made it a team issue. There are a few of these DRY violations but again: If you do not intend to read the book like I did from one end to the other because you are a i.e. a Project Manager or Product Owner the chapter itself has great value.

Final thoughts: Read this book if you in any way are working with developing and delivering software. The book can provide you with tools and thoughts which you can use to ease communication. Furthermore it digs into basic tools and patterns on how to attach various concepts of software engineering. I enjoyed 95% of the book and compared to the vast majority of the books I read nowadays 95% is well above Good Enough for me ;o)


Links: The Pragmatic Programmer website