Posts tagged as:


You can get the video version of this podcast here.

David Heinemeier Hansson sparked a debate on Twitter about Ruby testing frameworks. A lot of people saw it as slamming RSpec and others saw it as constructive conversation about what tools you use and why. This is how I view to see it and where I come down on this debate.

I also discuss why we have these debates in general and what we can learn from them.


At Mountain West Ruby Conference, Mike Moore brought up that many members of the Ruby community have lost part of the community roots. Particularly, the acronym MINASWAN, which stands for “Matz is nice and so we are nice.”

There are a lot of people out there who, rather than looking to help, are looking to fight or trying to look good. The funny thing is that if you can make a real contribution, you do look good. So, here’s a discussion on how to contribute to the community in a positive way.

Download this Episode


Asking people what Agile development is is like asking people what math is. You could get answers varying from specific operations to branches of math like algebra or calculus. The answers the Agile question vary from specific practices of certain Agile methodologies like pair programming, standing meetings, sprints, and sprint boards to ‘not waterfall.’

The real answer depends on which question you’re trying to answer. “What is Agile?” usually translates to one of the following.

  • What is at the core of Agile development?
  • What is the purpose of Agile development? What is it trying to solve?
  • How do I implement Agile development?

Let’s dig into these questions.

What is at the core of Agile development?

The traditional core of Agile development is the Agile Manifesto. The Agile Manifesto states:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

I wrote a post over at the Business is Pleasure blog on where agile methodologies break down. The post also covers the general principles behind agile development. Since I don’t want to duplicate content, I’ll summarize here.

In general, the focus of the Agile Manifesto is basically to:

  • allow people to excel according to their strengths, rather than according to the system.
  • make sure software works, rather than get caught up in documenting what it should do.
  • make the software usable.
  • involve the end user and business people before you march too far down the wrong road
  • adapt to changes—after all, we’re dealing with real life, here.

What is the purpose of Agile development? What is it trying to solve?

Most Agile proponents would answer this question by explaining the Waterfall method. However, I think the supposed anti-pattern that the Waterfall method represents distracts from the point of Agile development rather than defining it.

Agile development is really about providing a framework that allows developers to build something useful for real world users and deal with the realities of interruptions, timelines, and technical requirements that disrupt an ideal development cycle. In other words, Agile development helps developers deal with reality.

Certain practices, such as iterations, pair programming, code reviews, and retrospectives help developers and development teams adapt to change, avoid or fix bugs, and find ways to employ their strengths to build great software.

Let’s face it, if a programmer or team knew what the ideal product was when they started coding and could work uninterrupted until they were done, they would get pretty close to the ideal product. However, product development never works this smoothly. Typically, a prototype is developed, shown to a few users, taken back to the drawing board to be molded into a better prototype, over and over again until a prototype appears that is good enough to be called a ‘product.’ We then stamp a version number on it and ship it.

Agile helps us deal with these types of interruptions and reworks that are part of the reality of building software.

How do I implement Agile development?

This is where the things get crazy. Everyone seems to have a horse in this race. The Extreme Programming (XP) people think they have the ultimate way to build software. The Scrum folks think the XP folks have missed the point in some aspects. The big name agile coaches and book publishers want you to follow methodologies that benefit them.

So, what is the right way to go? A lot of people will tell you a lot of things. The one thing that many people won’t tell you is “Do what works for you.”

Agile development’s first tenet according to the Agile Manifesto is:

Individuals and interactions over processes and tools

This tells me to do what makes for the most effective interactions and individuals. This implies that you know your strengths. If you don’t, don’t worry. You’ll figure it out as you go.

I recommend to most people that they look into XP, Scrum, or some other Agile methodology they’ve heard of. Choose one or two of their practices and try them out. A good try will occur over a few months. If they don’t work after you’ve gotten used to them, find ways to modify them so you can get the benefits from them and minimize the problems you’re having. Or stop them altogether.

The Agile methodologies are a good roadmap for solving your programming process’ problems, but they are not the destination. The destination is great code. The practices behind Agile methodologies can show you the roads to get you there faster.

I’ve never met anyone who had 100% adherence to a particular methodology work for them. But I’ve seen people get close and get results.


Overall, the confusion about Agile development comes from one of its strengths. You define how Agile works for you. It’s similar to the principles of good living that most people get from their religion. There’s a huge amount of overlap in the religions out there, you just have to find what you believe to be truth and then do your best.


During the summer of 2009, Eric Berry began recording screencasts about Ruby and Rails similar to the screencasts at He also invited other Rubyists to join him and provide recordings for the Ruby community. This is where I got involved. I did my first screencast for Teach Me To Code on Ruby on Rails Routing. This resulted in two things. First, I realized that recording wasn’t that tricky. Second, TechSmith sponsored my efforts by donating a license for Camtasia Studio for Mac and an AT2020 USB microphone.

Having been a longtime podcast listener and feeling empowered by the success of a screencast, I decided to start a podcast. I contacted Gregg Pollack and asked him about recording podcasts and got a lot of great advice from him about putting one together. In the process, I interviewed him as the first recorded episode of what became the Rails Coach podcast.

After a few more months, I had built a small community around the podcast. At the same time, Eric was becoming more interested Groovy and Grails and was focusing on other things related to his family and career. Recognizing that the majority of the audience at Teach Me To Code was Ruby and Rails developers and that his interested were taking him in the direction of Groovy, Eric asked me to take over providing the screencasts and managing the site.

I became the primary producer of screencasts in April 2010. Eric is still involved as a content producer. I combined the Rails Coach podcast and renamed it the Teach Me To Code podcast and incorporated a blog for articles in May 2010.

Eric has done an amazing job setting up systems such as the Disqus comments and UserVoice forum for suggestions. I have been extremely happy to move things along and keep the community and discussion alive.

{ 1 comment }

In this episode, Chad discusses how he broke out of a comfortable job as a forklift operator, which ultimately led to him becoming a programmer.

He discusses his job, Ruby Central, and the Pragmatic Studio as contributions he makes to the community.

We also discuss the ebb and flow of passion for programming and how to avoid burnout on the things that we love. [click to continue…]


This week I interviewed Chad Fowler. He and several others have helped organize Ruby conferences around the world, most notably RailsConf, RubyConf, and RubyConf India. He has also written The Passionate Programmer and Rails Recipes. Finally, he has contributed to open source projects like RubyGems and Facebooker.
[click to continue…]

{ 1 comment }

In this interview with Pratik, we discuss several things, including:

Download this Episode

{ 1 comment }

Download this episode

Subscribe in iTunes

Remember to leave feedback by calling 801-753-8279 or emailing

Conferences are a great way to learn and meet people.

The conferences I’ve attended:

Tips for getting the most out of conferences:

[click to continue…]

{ 1 comment }

Download this Episode

During the interview with James, we talked about several things. You can find him on twitter at

James ran the RubyQuiz for 3 years and wrote Best of Ruby Quiz Volume One (Pragmatic Programmers) and Textmate: Power Editing for the Mac (Pragmatic Programmers).

[click to continue…]


Download this episode

Why Another Rails Podcast?

Basically, many of us need someone who will encourage us and share our passion for what we do. This podcast is designed to help push you to become a better developer and to help you find people who are as crazy about programming as you are! Excellence and collaboration are the goal!

[click to continue…]