WAIT! Stop Right There!!! I know some of you saw Ruby in the title and are about to move on, but I encourage you to read on. This could be beneficial to you even if you don’t know or don’t care about the Ruby programming language.

Podcast Description

For those of you who listen to podcasts while driving, mowing the lawn, running, cleaning the garage, or lounging at home, here is a recommendation of something I like and listen to. Like many, there aren’t always enough hours in the day to keep up with various topics and I like to listen to podcasts when I can to keep up.

Our reading audience are technology folks, usually involved with delivering software using an Agile or Lean approach. This podcast recommendation isn’t explicitly Agile or Lean focused, but those elements can be found here in there along with healthy doses of pragmatism. While there is a focus on a specific language I have found a wealth of good knowledge and discussion often applicable to general software practitioners of any technology set.

Agile Velocity has a lot of experience working with Ruby on many projects over the years, which led me to the Ruby Rogues Podcast. This is a group of Ruby practitioners who lead a weekly panel discussion of Ruby and Software Development topics with frequent guests from the community. Many of the regular hosts are well known in the Ruby community and are also authors and conference speakers. Each episode also ends with fun technology (and sometimes non-technology) picks by the panelists.

This is an easy recommendation for anyone who works with (or is considering) Ruby. But there are many episodes that focus highly on general software issues around development, delivery, agile, technical practices, craftsmanship, etc.

Recommended Episodes

Here are some episodes that general agile software practitioners may find interesting:

• Rescue Projects: A discussion of projects that have become problems and how to approach them, including dealing with legacy code and designs
• Book Club: Practical Object-Oriented Design in Ruby: A discussion with the author about learning and applying good Object-Oriented Design. This is timely because many people in the Ruby community came to programming with little formal OO training.
• Learning From the Past: A discussion about standing on the shoulders of others and how to learn and improve our skills by looking at past experiences (ours and of others)
• Complexity (with Glenn Vanderburg): An examination of what complexity is, it’s effects, and how to deal with it
• Service-Oriented Design: A look at applying Service-Oriented design
• Book Club: Growing Object-Oriented Software Guided by Tests: A discussion with the authors about testing, design, object-oriented principles, and software architecture. This is one of the best books on the subject of TDD.
• Functional vs. Object-Oriented Programming (with Michael Feathers): With the recent resurgence of interest in old and new functional languages there are many people trying to compare these paradigms and evaluate when/if to use them.
• SOLID (with Jim Weirich): Using SOLID principles of Object-Oriented design
• Domain-Driven Design: Like it says, a discussion of Domain-Driven Design, technical practices, design patterns, ubiquitous language, etc.
• Agile Communication (with Angela Harms): A discussion of Communication techniques and awareness for Agile teams
• Estimation: A discussion estimation, tracking/managing projects and measuring speed
• Software Craftsmanship (with Noel Rappin): The panel discusses the concept/manifesto of Software Craftsmanship, apprenticeship, Code Retreats, etc.

It was difficult for me to pick just this list because there are so many more great episodes. While this is probably nothing new to people in the Ruby community, I hope I have pointed the rest of you to one of the best software development related podcasts around that most software practitioners can benefit from.

I used to cringe when I heard developers say they were going to refactor some code.  To me, as a tester, that meant they were going to change working code and possibly introduce bugs into the software.  If it ain’t broke, don’t fix it, right?  Why are we refactoring it?  Truly, the answer lies in basic Agile practices.  Agile teams implement lean code that meets the user’s needs, then we put the code in front of the user, get feedback, and continually evolve the code based on that feedback.  We also implement code knowing we need to learn about our design decisions. Sometimes what we learn is that there is a better way to design the solution.  All of these practices require code to be refactored.  It is not a bad thing.

However, what can be bad, is when a developer cannot make changes to some code because the code is too complex, or it is unclear what the code does.  If there are no unit or integration tests automated, then it becomes risky to make changes and ensure there are no regressions in functionality.  The best Agile teams understand this and ensure there is automated test coverage as features are being written.  They rely on these automated tests for rapid feedback.  They can refactor their code (or code other’s have written) with confidence.  The code remains testable, simple, and maintainable; all of which save time and heartache later on.

So, testers should not fear code refactoring.  We should work with developers to put unit and integration test frameworks in place on our projects.  We should help our teams increase unit test coverage.  We should encourage a team culture that embraces refactoring.  We should only fear brittle, untestable code that must be retested manually after major code changes to existing functionality.  I’ve tested code like this and I don’t want to do it anymore.  I’m smarter than that.  And so are you.