Practices of an Agile Developer

Before I was even finished reading “Practices of an Agile Developer” by Venkat Subramaniam and Andy Hunt, I realized that it was going to exceed my expectations. I consider a lot of the practices in which I’m engaged in daily to be good agile practices. It wasn’t until I read Venkat and Andy’s descriptions of them that I truly appreciated the practices I regularly partake and learned about many others that I’m not participating.

The authors describe 45 practices in the book. They go over things like “What it feels like” and “Keeping your balance”. The signs you’ll notice and feelings you’ll feel when you’re doing it right, and pointers on not getting in over your head.

I can’t cover them all, but I’d like to touch on a few that stuck out in my head.

The Bad

There were a few practices of which I would say I’m not doing a good job. I wouldn’t have read it if I didn’t think I’d learn something right? Here are few I noted that I couldn’t relate to when reading “what it feels like” when you’re doing correctly.

Be a Mentor

Aside from helping others out at work or going over code after user groups and code camps, which I wouldn’t consider mentorship, I’m definitely not a mentor to anybody. The next closest thing would be blogging and presenting at code camps and user groups. I have done this so I’d say I’ve participated in some type of mentorship, but there’s still much room for improvement.

Keep a Solutions Log

With the combination or mix of unit testing, test driven design or just test first, I usually think I do a decent job of eliminating defects early in the development process. There will be bugs that show up from time to time though. One thing I’m not as good at doing is keeping a solutions log. At work, we use Trac for our defect tracking tool and I’ll find myself getting lazy and adding something like: “Fixed with revision 6230” or something to that effect. I may not always noticed, but the details of the defect sometimes aren’t written down very well. We might have the result of the bug and how to replicate it, but when closing it with some boring message like I stated above. Another developer viewing it later on might not understand the full implications of the problem. Within our team, questions have risen about previous fixes and I wasn’t able to articulate them as well as I wished I could have. The authors suggest that it should feel like an extension of your brain… I’m not recording enough to be at that point yet. I’m good about recording the “what” and “when”, but working on improving the “where” and most importantly, “why”.

The Good

There are recommended practices that I think my group and I follow quite well. I selected a few to talk about that I think are very important and I’m proud we’re doing so well at keeping up with these.

Criticize Ideas, not People

I work on a team that is very open and honest. Sometimes I’ll forget I’m not at work and be very critical of something that somebody is doing. People don’t always take kindly to criticism, so I’ll get dirty looks. Within our team this type of criticism is not taken personally; we’re all part of the same team trying to do the best job we can for our company. I’m also lucky to work with a group of individuals that focus on quality and aren’t just there to collect a paycheck so they can spend it on the weekends. Because we’re often criticizing ideas, questioning the “way things are” and continually improving our process, we’re creating a better work-place for ourselves.

This practice talks about how you can interact with your colleagues to create an environment of respect, trust, pride and cooperation. Venkat recalls and talks about a real-life scenario where he learned a valuable lesson from a senior administrator. This senior admin could have pointed the finger, but decided to remain calm and help him with the fix. By working together they were able to fix what they needed and made everybody happy. This reminded me of the Collective Ownership practice the authors mention in Chapter 8.

Keep it Releasable

Small iterations and a short feedback loop make keeping it releasable easy. If you’re always making sure that you keep the code base in better condition than when you left it, you shouldn’t have a problem with this. The single best way to do this that I can think of is running unit tests in a continuous integration environment. The best part of this practice is that you can do it for free. Andy and Venkat describe this feeling as though you can always show your latest code without hesitation or fear. The project is always in a ready-to-run, stable state.

Final Thoughts

Many of the books I have on my shelf are more of a reference book than books about ideas and practices. This one will continue to be an excellent resource for bettering myself as a developer and a team member. I’ll probably end up reading this book a few times a year just to make sure that I stay balanced!