From the monthly archives:

June 2010

The second part of the tutorial for building a blog with Ruby on Rails version 3. We demonstrate how to set up some basic routes, manage the controller and views, and create a basic form for creating posts.
Download 161.4 MB
Download (iphone & ipod) 65.8 MB


I’ve been thinking about the podcast and realized that I haven’t told my story. So, I’m going to talk about how I got into programming and technology. It’s a story that started early in my life and leads through my college years and into my career.

I love programming and helping people and I would love to have more time to do that, but that means that I need to build a business that lets me do that. I’m not begging for money. But I would like your input.

BTW- Sorry for the scraping noise. I didn’t realize my mic was picking up my mouse scraping across the table.

Download this Episode


Every good project needs a good setup. In this episode, I set up a github repo, create a new rails application, hook in Cucumber and Rspec, write a Cucumber feature, and write the code to make it pass.
Download 142 MB
Download (iphone & ipod) 59 MB


Eric has his own company at He’s a freelancer and is developing a new product called Agile Dash.

Eric is bootstrapping his company. Some of his inspiration comes from Peldi from Balsamiq Mockups and Joel Spolsky.

Eric does his prospecting through LinkedIn, Facebook, and Twitter for his freelance business.

Here are some books recommended in this episode (affiliate links):

On Business:

On Programming:

Download this Episode


This is a discussion of the practice of Continuous Integration or Continuous Builds. Continuous Integration is a very important part of insuring that your code is of the highest quality. It runs tasks against your code that provide you information like whether your tests pass or your code compiles.

The services I’ve used to do this are:

You can use Continuous Integration to do the following:

  • Catch failing tests
  • Run and compare metrics
  • Verify your development process
  • Trigger deployments

Things mentioned in this podcast with links:

Download this Episode


This was a fun interview with Bryan Liles. Bryan is a very expressive guy. He’s noted in the Ruby on Rails community for TATFT (Test all the f*ing time) and his blog at

In this discussion, we talk about TDD (Test Driven Design), TATFT, Lifehacking, leaving the mouse behind, and opinions on software.

Some things mentioned in the podcast:

You can check out his blog and follow him on twitter.

Download this episode


RSpec gives us many powerful tools to make our tests readable. Matchers allow us to provide custom predicates to our should statements that succinctly define the behavior of our code.
Download 27 MB
Download (iphone & ipod) 14 MB


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.


This year’s Agile Roots conference is focused on building great software. They have a terrific line up of speakers and it only costs $250, which makes it a great deal! The conference this year focuses on the development process and how it formulates requirements that lead to great software. Not just great software to maintain and build. But also great software that provides value to users.

Andrew explained that we, as developers, need to realize that we’re enabling a business experiment, not just building code.

He also went into the value we receive from open source software. The problem some of these people have is collecting the value of their work. You don’t get paid for being smart. Rather, we need to find ways to receive value from what we’re providing, even if it’s not designed specifically to make us money.

Pat Maddox wrote a blog post called “Are you punching your users in the face?” It was designed to help people to understand was that the value of the code isn’t in the tests or the code itself. Its value is in building software that users want to use.

We got a great recommendation to read “A Big Ball of Mud”. The author asked “What do you call someone who writes code like this?” after talking about every antipattern and code nastiness and he said “millionaires.” Historically this is true. Someone solved someone else’s problem with ugly hacky code, and walked away with millions of dollars.

We tend to discount sales and marketing personnel, when they are the ones that make your money. They build the brand and they bring the money in, even if you don’t have the best products.

Tim O’Reilly said, “Create more value than you capture.” If you do this your users will love you and your community will grow and support you.

We go into the idea economy and how agile ties into the idea economy. People are trying to sell each other on their ideas in agile as much as anything else.

Andrew was first introduced to Agile he found most of the practices as wasteful, painful, and wrong. So, he started discovering the roots of Agile. What he found was that Agile was bout solving our problems with our strengths. Once he started going to the Agile Round Table, he found that it was actually about delivering working software.

Over the last year and a half, Andrew has been working on taking agile into other areas of work.

The term ‘agile’ has become overloaded. Some people say agile, what most people mean is a watered down half implemented version of scrum.

Agile, the word, has crossed the chasm. The practices haven’t.

Trying to agile isn’t what you should do. You should be trying to be awesome.

Listen to the interview for some great tips on being awesome.

Here are some links to following Andrew:

Twitter: littleidea


Download this Episode