Chad Fowler's Blog, page 2
February 10, 2011
McDonalds, Six Sigma, and Offshore Outsourcing (notes)
These are notes from a talk I've given in various forms at SCNA, CodeMash, and Magic Ruby. I've mirrored them here from the InfoEther weblog.
Me at SCNA
Photo credit: Monty Ksycki
The presentation is called "McDonalds, Six Sigma, and Offshore Outsourcing – Unexpected Sources of Insight". Here's the abstract:
We software developers like to think of what we do as an art form (or a craft, if you're at this conference). I was once asked to come up with a set of guidelines for creating great software so our (huge) company could more effectively use an offshore development team that had been delivering amorphous piles of crummy, nonworking code. I was frustrated and responded with something like this: "Give me a list of guidelines for how to make a beautiful song!" The nerve! Repeatable processes? Who did she think she was talking to?! This is a creative process! This is ART!!!!
I've since grown up a bit and I'd like to talk about how I was wrong and how we can all hopefully learn from my mistakes.
The Art-Craft-Commodity Continuum (from my presentation)
In it, I tell the story of my experiences with the Six Sigma quality methodology and with offshore outsourcing, urging developers not to blindly write off potentially useful software development strategies based on hearsay and misunderstanding. I also propose a customer-driven, data-driven approach to software engineering, dovetailing off of InfoEther's Chief Scientist, Glenn Vanderburg's recent ruminations on "Real Software Engineering".
The original Ronald McDonald (Willard Scott)
Videos from SCNA will be posted on InfoQ eventually, and I'll link mine here when that happens. In the mean time, many people asked me for pointers to some of the books and resources I mentioned during my presentation. Here's a link dump that you might find useful:
Wilson Pickett's Mustang Sally
Zen and the Art of Motorcycle Maintenance: An Inquiry into Values
The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About It
VMG BPO – Offshore business outsourcing
Ask Sunday – Virtual Personal Assistants
GlowTouch – Low cost offshore IT outsourcing
iSixSigma – Lots of six sigma info
DMADV – the six sigma design process in a nutshell
Design Patterns: Elements of Reusable Object-Oriented Software
Forbes article on Ray Kroc and the founding of the McDonalds chains
John Zorn – Avant Garde saxophonist
Mark Rothko – Abstract Expressionist painter
Ugly Kitty Server code by me and Anthony Burns
The "I know it when I see it" Supreme Court case
Ibn Al-Haytham – inventor of the scientific method
Extreme Programming flow chart
Keavy McMinn's webblog on Ironman etc.
The Passionate Programmer – My book
February 9, 2011
Rails 3 Recipes needs tech reviewers!
UPDATE: We got 8 times as many volunteers for Rails 3 Recipes reviews as we need. You people are awesome! Closing the call for help now.
The original Rails Recipes has been used by tens of thousands of Rails developers as they've worked toward mastering everyone's favorite Web framework. Five years later, and after the release of Rails 3, we're seeing a new wave of Rails developers. Through my work with InfoEther and The Pragmatic Studio it's clear that an updated version of this classic would help a huge group of new Rails developers.
So here comes Rails 3 Recipes!
I'm a little over half way done with the new edition, which is full of both substantially updated and entirely new content. Now I need your help.
Before we take the book to Beta, we need technical reviewers. To tech review, you need to either already know Rails fairly well or be interested in trying to use the book to learn (some Rails knowledge is assumed).
In return for your comments, we'll give you a free copy of the electronic and paper versions of the book as well as a mention in the book itself.
Interested? If so, please contact us at rails3recipes@gmail.com and let us know your level of Rails expertise. We can only handle a certain number of reviewers (probably 15), so we'll be limited to accepting the first who get in touch.
To those who are interested, THANK YOU!!!!!!
If the original Rails Recipes' success is any indicator, Rails 3 Recipes is going to be the book every Rails developer will have sitting on his or her desk over the next couple of years. I'm very excited about it and looking forward to some feedback.
How Rails Developers do Ajax (with jQuery) in 2011
Wanting to survey what the current state of the art in Rails Ajax development is, I asked this question on twitter:
I got a lot of great responses! 44 last time I checked. Here's what I found out people are doing:
mustache.js
Sending JavaScript back down to the client using .js.erb template files (Ryan Bates linked a couple of examples here and here)
JQuery templates
Hitting RESTFUL endpoints and responding with JSON data to be manipulated on the client
Using backbone.js
Rendering partials and updating elements on the page with their raw content (the original old-school Rails way of doing it)
Use SammyOnRails
There is definitely a divide and a lot of opinion (suprise!) between those who are OK with delivering JavaScript and/or HTML from the server to be rendered on the client and those who prefer to deliver data and have the client process it. I'd characterize the former as the less clean, more pragmatic approach and the latter as the idealistic cleaner approach. It seems that tools like mustache.js, backbone, JQuery templates, and Sammy.js are tightening the gap between quick + dirty and slow + clean.
What do you think? What did we miss?
January 15, 2011
I Don't Know
I had the pleasure of watching Scott Chacon keynote at CodeMash this week. He spoke about how Github "manages" its development team and product development. I enjoyed the talk, and encourage you to download his slides if you weren't at the conference.
Scott is a very energetic speaker and talks really fast, so he ended his keynote with a lot of time to spare (something I wish I would do more often). So he took questions from the audience.
A lot of the questions were about trying to fit Github's process into companies of very different profiles. So, for example, "Would this work in blah blah blah environment that is totally different from Github?" Scott's answer was excellent in these several cases:
"I don't know."
He didn't blow the questions off. He then discussed possibilities. But it was incredibly refreshing to hear "I don't know" from a speaker being questioned in front of an audience of almost 1000 people.
I wrote in The Passionate Programmer about the difficulty and importance of learning to say "no". I think "I don't know" is scarier and harder and maybe more important.
When someone regularly says "I don't know", you trust them more when they say they DO know.
