Practices of an Agile Developer

Practices of an Agile Developer

Thankfully when I finished reading Practices of an Agile Developer I didn’t feel completely despondent.

My career, at least for the last twenty or so years, has been as a software developer (I’m still searching for that elusive second career). So I couldn’t help but relate the advice and tips given to my previous, or indeed, my current employment situation.

It’s good to read that ideas that I’ve implemented over the years are the same best practices that the book describes: using a version control system, writing build automation scripts and having a central ticket logging system. The one thing that I don’t do is keep a log of what I’ve worked on, the problems I’ve come across and how I’ve solved them. That’s something I need to start.

One sad point is that never in my career have I polished or re-factored any code… ever. From that little nugget you can also deduce that I’ve never written any automated tests, which are the bed-rock of re-factoring. It has always been the case that as long as it works that’s it.

It’s a good, easy to read, book that I didn’t really get all that much information from. Possibly because I’ve read so many development books and blog posts over the last few years that I’ve heard most of the advice that’s given. If you are just starting in a career as a developer then it really is a must read.

Throughout the book there are graphics of devils and guardian angels. Generally the little devils are telling you to take coding shortcuts, needlessly duplicate code to make changes quicker and don’t even bother with testing. The angels are always saying that best practices are named so for a reason, but in the end the devil gets the best lines:

You need to hold meetings - lots of them. In fact, we’re going to keep scheduling more meetings until we discover why no work is getting done.

Another part that made me laugh was describing how to attack debugging code by breaking the application components into more manageable parts. Not all that easy if the code is written as one huge chunk. This is described in the footnote as the “Big Ball of Mud” design anti-pattern. We use the same practice at work only I wouldn’t describe it as “mud” exactly, same colour and consistency, just not “mud”. It’s only funny because it’s so true.