Chad_sq_150

Chad Fowler

Chad Fowler has been a software developer and manager for some of the world's largest corporations. He recently lived and worked in India, setting up and leading an offshore software development center. He is co-founder of Ruby Central, Inc., a non-profit corporation responsible for the annual International Ruby Conference and The International Rails Conference, and is a leading contributor in the Ruby community. Chad is a contributor and editor for numerous books and is author of My Job Went to India (and all I got was this lousy book) - 52 Ways to Save Your Job, Rails Recipes and the upcoming Advanced Rails Recipes.

Badge_rubyconf10_sm Badge_railswhitepaper Rackspace_partner Badge_training

Articles by Chad Fowler

Things I mentioned in my Ruby Nation presentation

Posted by Chad Fowler on 15 June 2009 00:00



Photos by Dave Bock

I had a great time at Ruby Nation this weekend. After my presentation I got a number of questions asking about things I referenced during the talk. Here’s an attempt to point to some of them. If you weren’t there, you won’t have any context but feel free to follow the links anyway You might find something interesting.

My Book

Bureau of Labor Statistics Time Use Survey

Stockholm Syndrome

Karlheinz Stockhausen whose name I accidentally used when trying to refer to Stockholm Syndrome.

4d Database

John Coltrane

da Vinci Sketches

Eight Hour Burn

XP (Agile) Immersion

Pat Metheny – “Whenever young guys ask me what they should do to get better, I always say try to be the worst guy in whatever band you’re in. That’s the secret.”

I Will Teach You To Be Rich

Purple Cow

4-Hour Work Week

Wozzeck by Alban Berg

Drepung Gomang Institute (for whom we translated Hindi)

What Would You Rather Be Doing?

Ask Sunday – the company I mentioned that helped me with research

My exercise bike

Arduino – I used this to create the interface to my exercise bike

Gosu – The game library I used to write my exercise bike “game”

Building Games with Ruby – Andrea O.K. Wright’s presentation on game development in Ruby

You and Your Research – Richard Hamming at Bell Labs

Fixing Broken Windows: Restoring Order And Reducing Crime In Our Communities

The Pragmatic Programmer

Discussion Panel: Women in Rails

14 Worst Health Mistakes Even Smart Women Make – Referenced Harvard and University of Texas studies on the effect of the company you keep

How to Call Attention to Your Music – Derek Sivers free ebook

15 Things Kurt Vonnegut Said Better Than Anyone Else Ever Has Or Will


Your Customers Aren't Idiots

Posted by Chad Fowler on 05 December 2008 00:00

I was in a customer conference call with John Athayde recently, and he did something really smart. He was talking about his in-progress design for the customer's product and he wanted to explain that we would have reusable snippets of the design which would allow us to consistently provide the same view of an important part of the system whenever it would show up. This being a Rails project, we would do this using ERb partials.

So, John said, "We will extract this out into little snippets that I'll call -- partials". And so on.

He could have made up a metaphor and used a new customer-friendly term for this. Or he could have explained that we're using Rails, and Rails supports this thing called "partials" which is... blah blah blah. But the former requires us to learn a dumb new word just for this project, and the latter is too much information. The term "partial" is a pretty good one to describe what it does. In fact, in most well-designed systems, the terms the system uses to describe concepts are pretty good. Pretty easy to understand.

For some reason we developers feel compelled to hide these terms and concepts from our customers as if they're children that can't be trusted with sharp tools. They're not idiots. They just know different things than we do. Imagine if they tried to hide their terms and concepts from you because they assumed you were unable to understand them.

I saw Martin Fowler speak at an XP users' meeting several years ago, and when he got to the practice called "system metaphor", he said he didn't really do that practice so much anymore because (paraphrased from iffy memory), "Sometimes the best metaphor for a system is the system itself". Note to self- keep that in mind more often.