Writing I mention frequently

Everyday Scripting with Ruby (Amazon) is my book to teach Ruby to nonprogrammers. There's a sneaky twist to it, though: because a programmer's formal education often mimics the development of the field, what's newer often seems harder. She has to learn and unlearn things in the order the field did—so objects seem harder than procedures, closures (lambdas, blocks) seem harder than functions, recursion seems harder than iteration, and test-driven design seems unnatural. But for people unburdened by history, what's newer is actually easier. Since those people are my audience, I can teach them the good stuff right off. For that reason, some programmers find the book useful too.

I often get asked how testing should be done on agile projects. The real answer is, "well, it depends," followed by questions. But I have biases, just like anyone else. I wrote those biases down in 2004 in "A Roadmap for Testing on an Agile Project." It's still a reasonable short description of my biases today. You can find a longer description of the thinking that led up to that summary in a series "Agile Testing Directions." The first of those introduces a popular 2x2 matrix that contrasts business-facing to technology-facing tests and also tests that support the process to tests that critique a product. (In the previous, you can substitute "tests" with "examples".)

When consulting, one of the things I'm aware of is that it isn't ideas that build products, it's people, and people have quirks. One is the importance of tacit knowledge: experts often have no theory of their work. They simply perform skillfully. The other is the interweaving of process and personality. As I put it in the linked article, every article on methodology implicitly begins, "Let's talk about me."

I was one of the authors of the Manifesto for Agile Software Development. Six years on, I realized that it was primarily a message from software teams to their businesses, proposing a contract. That contract has been signed: Agile development is now reasonably mainstream. The pressing issue now is how teams can fulfill their side of the bargain—because a lot of teams aren't. For them to succeed, they need to attend to four values that got left out of the original manifesto: discipline, skill, ease, and joy. My talk, "Six years later: What the Agile Manifesto left out" argues for that claim.