Published in Uncategorized
.
A week or so ago I downloaded the peepcode screencast on Test First Development. It was the first really clear example on Test Driven Development I’d seen and it helped clear up a lot of questions I’d had about it.
I was introduced to the idea of writing code based tests when I started learning about Ruby on Rails. When learning PHP (or any other language for that matter) it was not something mentioned in any of the literature I had encountered. But as Rails takes an “agile” approach to things, writing tests are an expected part of development.
Shortly after beginning my exploration of Rails I was hanging out in the #railsonrails IRC channel and Luke Redpath was talking about Behavior Driven Development (BDD) a variation of Test Driven Development (TDD). I was totally lost but wanted more information. He suggested reading Kent Beck’s book “Test Driven Development By Example” first and get familiar with that before trying to wrap my head around BDD. I promptly added it to my Amazon Wishlist and there it stayed until today. After watching that peepcode episode, I decided that I would finally plunk down for a copy of the book and today it arrived in the mail.
As the title suggests, this is my first book specifically about Agile Methodologies. While the Agile Web Development with Rails book is technically an Agile book it is more about the Rails framework than evangelizing and explaining any specific processes or philosophies. I’m looking forward to exploring the world of writing automated tests for my code prior to doing any sort of development. Hopefully it is as helpful as I expect it to be.
Published in Uncategorized
.
Well in my effort to develop my programming skills I’ve spent a lot of time listening to various software engineering podcasts lately. The most common theme throughout the podcasts has been Agile Development in its various forms. Some dealt strictly with XP and others dealt with Agile in a more general sense.
One person interviewed on two separate podcasts really caught my attention: Alistair Cockburn (pronounced Coe-burn for the non-Scottish). One of the original founders of the Agile movement, and someone who spent several years actively researching software development methodologies, Alistair’s approach was very practical and refreshing.
In an nutshell, he found that anything that made a development team work better together was good and should be kept and anything that inhibited productivity should be tossed out. The humor of this is emphasized in the fact that Alistair is a Ph.D.specializing in methodologies and has developed his own Agile methodology called Crystal Clear.
To be sure, he does identify certain practices that when applied often lead to an increase in productivity. However what separates Alistair from most other Agile methodologists is that he is not rigid in the implementation of his or any other best practices. This was captured in a story he told about how he was brought in to an organization implementing XP and struggling with the weekly meetings. The developers weren’t enjoying them and as a result were not benefiting from them. But since they were a part of XP the meetings kept happening. Once Alistair discovered this, he suggested that they drop the meetings until the next evaluation cycle (3 weeks later) and see if losing the weeklies helped. The solution while simple was revolutionary to the team because it showed them that nothing was set in stone and that they could choose what worked best for them in the situation/project they were working.
When looking at Crystal Clear you get a clear picture of the best practices that Alistair values most:
1. Frequent Delivery
2. Reflective Improvement
3. Osmotic Communication
4. Personal Safety
5. Focus
6. Easy Access to Expert Users
7. A Technical Environment with Automated Tests, Configuration Management, and Frequent Integration
Each of these are relative and flexible in their implementation and need to be defined based on the values of the development team and the requirements of the project but when applied they consistently yield an increase in productivity.
What makes this approach so refreshing is that the ultimate goal of the methodology is to help development teams make better software and enjoy the process. The flexibility on the specific implementation of methods while holding fast to the values that inspired those methods is profound and shows a true grasp of the complexities that each project has the potential to bring to the table. Ultimately it also comes closer to the values espoused by the Agile Manifesto than other methods that are more rigid in their implementation.
Wednesday Rails 1.1.3 was released, but apparently it broke a lot of apps, 1.1.4 was released today to fix this. One of the comments I found on Ryan’s Scraps and another on Riding Rails noted that there is a lack of a changelog for releases. This seems to be a problem of the agile way, namely that documentation is not really seen as neccessary.
Is documentation neccessary? As a developer I hate having to document code, especially when I’m “in the zone.” However when I have to read other peoples code, or when I have to come back to code I have previously written I am ever grateful for proper documentation. When it isn’t there, it can be a real nightmare to figure out what is going on.
Documentation is also neccessary when you are dealing with someone elses code that is being developed independently of your own. You need to know what to expect if any changes have been made or there are new features that you can take advantage of.