First off, this is my first book review! I have a ton of books and always enjoy reading new ones to keep up on the latest in technology. Since recently starting up this blog I figured I would start reviewing them as well. Please note that in these reviews you will not find any nitpicking on grammar issues like you might read on Amazon as I will try to focus on the core of the book and if I got anything out of it.
So I just got done reading Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt. At 177 pages the book is a quick read. As with other books in the Pragmatic Programmers series, the book comes with a nice little tear-out “cheet-sheet” which covers the main points that were addressed in the book so that you can quickly refer to them while at your desk or tack it up on the wall.
In a nutshell the book covers habits of programmers, both good and bad, while trying to encourage the reader down the good size and to be well aware of the pitfalls of having bad habits. The book covers many of these habits and a few of them that I agreed with the most are as follows:
One of the first points in the book covers the notion of “not getting into the blame game”. Many of you know what its like when you are on a team and something goes wrong, some folks start pointing fingers rather than just working towards fixing the problem or finding a new solution. I really agree with this, as many times I have seen people get in arguments over who did what which is totally unproductive. My philosophy is “what is done is done” and lets make sure it does not happen in the future, assess the situation, learn from this and immediately resolve the problem. What is the point of dwelling on a “who did what” discussion!
Another point that I liked was the “integrate early, integrate often”. This is a must, just like iterations where you get new ideas and code out there for testing and to the users for feedback, it is critical that if you have a 3rd party integration, you treat that no differently.
“Develop in plain sight”: Ditto that. Getting your customer’s/clients to view the work in progress is critical. That early and continual feedback is so important. How many times have you forsaken that task only to get feedback once your deliverable is live? That… sucks!
“Keep classes small”. Agreed completely. As my software development career has grown throughout the years, more and more I’ve found myself trying to break each unit of work, task or whatever the problem is at hand, to a very specialized Class/object that does that one thing and does it well. This buys you so much more in the long run when it comes to decoupling and reusability.
“Collective code ownership”. I’ve been on a project where different modules were developed and owned by individuals, where other developers never really touched that code….until a problem comes up and the other developer is out of town… Don’t let your team get into that situation.
Overall the book is worthy of a read. The book is from 2006 but it’s content is pretty much timeless when it comes to software development. I think this would be a good book that you lobby your employer to purchase for your entire team, then have a meeting about it after all have read it.