Practices of an Agile Developer

I earlier reviewed my experience thus far with this book at http://johnragan.org/2009/11/12/practices-of-an-agile-developer/.  Now, I have finished reading it.

All in all, even though a lot of things weren’t new to me,  I would have to recommend this book.  I went through and summarized the contents in Evernote for later review, but I can’t share that with you (it would not be fair to Venkat)!  However, a couple of things did stand out for me:

  • Criticize Ideas, not People. Doing the opposite kills the cohesion of an Agile team in short order.
  • Invest in Your Team. We used to each study and present technologies or hold recurring group brown bags – what a difference it made!
  • Know When to Unlearn. Earlier I thought of the people I knew programming in C++ but still doing it as C. However, as I drove home listening to an old Pragmatic Programmer Podcast on Version Control with GIT by Travis Swicegood, I realized I had learned the GIT syntax for my GitHub account, but I was still using it as a substitute for Subversion as opposed to learning and embracing the GIT philosophy.  No wonder younger developers often use newer technologies more effectively because they are not encumbered with the older ways of thinking.  I have some more studying and unlearning to do it seems!
  • Communicate in Code. It seems we often code as if we are balancing a house of cards.  You coded a certain statement a certain way, but no one would never know why that way was important later on.  I have always (well, not always) strived to comment why I did things a certain way in these gotcha situations to help the next person come along.
  • Keep a Solutions Log. Why wasn’t I doing this earlier?!  This summer I started summarizing all the technical books I read in Evernote, but I will still not doing this for problems and solutions (until now).
  • Schedule Regular Face Time. Daily stand-up is not all that complicated, but doing it every day, at the same time, and keeping it short made a tremendous difference for previous teams I worked with.
  • Review Code. I was never a fan of this due to my earlier work on an SEI Level 5 environment on the Space Shuttle’s flight control software.  Lots of checklists, checking of the checklists, and so forth.  Between tools like FindBugs and PMD, as well as Peer Programming, I figured that was sufficient.  However, the latest research seems to show conclusively that this can really makes a huge difference.  I am currently unlearning my old opinion…

There are a number of other agile approaches covered in the book, with great ways to gauge how things are going and tips for implementing.  Hats off to Venkat!

Advertisements

One thought on “Practices of an Agile Developer

  1. Pingback: Practices of an Agile Developer « Learning Rails

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s