“All of this agile nonsense is just a fad. Don’t listen to the buzz. It’ll wear off eventually and all of those agile, pair programming nuts will move on to the next hot, new industry practice. You’ve never been agile before and it’s worked out just fine. Why start now?”
It seems as though the latest movement (read: fad) in the world of software development is agility. Everything needs to be made agile nowadays. The other day Chad interviewed a potential programming candidate. When asked about a line on his resume mentioning that he had experience in AGILE methodologies the candidate rattled on for about ten minutes about each aspect of the code that was agile, each of the practices that were agile, and everything else. Agile, agile, agile. It almost seems like a buzzword these days and it can be kind of hard to see past the smoke and mirrors of this whole agile development thing.
This book does not give you smoke and mirrors. In fact, you might be better served replacing the word agile. Go ahead and give it a try. The book is just as valuable if you were to say, “Practices of a Pragmatic Programmer,” “Practices of a Nimble Programmer,” or even “Practices of a Great Programmer.” Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt (of The Pragmatic Programmer fame) is a nice read detailing the 45 practices that agile developers can use to improve their code and their workflow. That’s right, increase your agility! Each chapter and section details a specific practice to ensure that you are on-your-toes agile. Now, when I say agile I mean “best practices that every programmer should follow and every team should implement.” Like the authors of the book, I do not recommend instantly practicing every tip. Some of these will not integrate with your process.
Like I said earlier, there are 45 tricks of the trade contained in this book. Implementing them all would be such a radical change, even the authors note you would be hard-pressed to jam them all into your current project. Some of the practices are key advice that do not require a process change such as: “Blame Doesn’t Fix Bugs,” “Don’t Fall For the Quick Hack,” and “Do What’s Right.” Most of the practices are definite should-dos that definitely should-not take a lot of effort such as: “Keep You Project Releaseable At All Times,” “Integrate Early, Integrate Often,” and “Measure How Much Work Is Left.” Other practices, might be a harder sell to get implemented easily like: “Treat Warnings Like Errors,” “Tackle Tasks Before They Bunch Up,” or “Use It Before You Build It.”
The book does a great job of briefly describing each practice, explaining why it will make your life so much better, and providing excellent example uses. (Is there anything Venkat and Andy haven’t seen?) I think in a world of verbose programming books, that really is undervalued. Each chapter, each practice is concise. They don’t bother with a five page history of how unit testing came to be. If you really, really need some history or anecdotal evidence, you will get the skinny. Mostly you are going to get two or three reasons why the practice will make your life easier. In fact, if you were wondering why I did the review of the book in the format you see here, that’s because this is how they layout every chapter. It begins with perhaps some common opposition to the practice as the devil on your shoulder. Then they go right on to the meat of the chapter, discussing the practice itself, the benefits, and an example of how awesome it worked. This is followed by the practice name (the one you’ll find in the cheat sheet in the back) with a description from the angel on your shoulder. To wrap up the chapter, they include how good you will feel for doing it right and some tips on how to keep balance. I really like these tips because if you become skeptical of the practice, it kind of shows you that there is a way to make sure you don’t overuse the practice or try to solve a problem that doesn’t make sense with it.
Read Practices of an Agile Developer. A good book is a good book just as good advice is simply good advice. It may seem like some of the practices in this book might not work for you. That’s fine. A lot of the text in this book, however, transcends agile as a buzzword. Agile does not mean a strict diet of pair programming, unit testing every single function of every single class, and using Erlang and Java for every project.
What It Feels Like
It feels good to stop planting time bombs in your code, staying nimble, and keeping your code nice and clean. A deep sense of accomplishment comes from within when you start realizing that you have cut down on bug counts as your peers point out those nested logic errors in a code review. There is a moment of zen to be found when your build machine kicks out the first working build. That new hire will give you a hug when he sees how the code-base is clear and, oh my, commented well!
Keeping Your Balance
- Don’t go out and grab this book just because I told you to. Go buy this book if you want to improve.
- This book IS a short read, but it is also a good one.
- Practices of an Agile Developer is not a magic bullet. You have to want to improve and you have to act on what you read. As noted in Pragmatic Programmer and Joel on Software, don’t let the higher ups get you down. Implement this stuff locally if need be.
