Robby on Rails

When I got back from Canada on Rails, I found myself looking at a review copy of Practices of an Agile Developer [1] sitting in our library. I haven’t had a chance to really dive into the book, but did take a few minutes to skim through a few sections that I found interesting.

Some bullets that I found useful.

• Don’t fall for the quick hack. Invest the energy to keep code clean and out in the open.

There have been times where I have found myself taking the quicker-well, it seemed quicker at the time-approach to solving an immediate problem.

• Keep your project releasable at all times. Ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment’s notice.

This is extremely important when there are several people working on one project. Developers have their own schedules and when we make a commitment to push new changes to a production environment, it’s important to be confident that all developers and designers involved in the project are following the same rule… test-before-you-commit. When this rule is followed, you aren’t concerned that if developer A needs to leave work early that the work that she checked in is tested. This allows us to push new changes to the production server at the end of each day if all tests are passing.

• Develop in increments. Release your product with minimal, yet usable chunks of functionality. Within the development of each iteration, use an iterative cycle of one to four weeks or so.

This is something that PLANET ARGON has been practicing more and more. Our iteration cycle is limited to 2-3 weeks, no more (unless there is a good reason to). When we are able to look at a distinct set of deliverables, which take 2-3 weeks to plan, design, develop, test, demo, and deliver, we can build our cost estimates around the number of resources that we be necessary to achieve those well-defined deliverables. It might only take 2 developers and a designer part time for those 2-3 weeks and we can adjust our cost estimates accordingly.

• Write code to be clear, not clever. Express your intentions clearly to the reader of the code. Unreadable code isn’t clever.

When Jeremy and I began working with each other last Fall… within a day of working around each others code… we decided to build a style guide for all of our code. This style guide has evolved over time… but the core principals remain. Keep your code… readable.

_“Remember your code is for a human first and a computer second.” _

- Martin Fowler, Refactoring

As I continue to review the book… I’ll post more thoughts. :-)

¹ Practices of an Agile Developer, Venkat Subramaniam and Andy Hunt, The Pragmatic Programmers, 2006.