Exploration Through Example

I’m ready for people to take a look at a chapter. It’s actually the second chapter of the book. The introduction, covering prerequisites, the general plan of the book, its goals, what “Cocoa” is, etc.—that will probably be written last.

But to orient yourselves:

• I assume you know Ruby, but nothing about Objective-C, Cocoa, or building apps on the Mac.

• Rather than build the exposition from the outside-in, teaching you first how to draw user interfaces, I’m working from Ruby up. I start with Ruby, start adding Cocoa ideas and tools onto it. The first chapter is very much like that—I’ll let you be the judge of whether it works.

• Especially in the beginning of the book, I want people to start changing code and seeing what happens. Might as well take advantage of Ruby’s fast edit-run loop.

The chapter and associated code are distributed as a disk image.

What am I looking for? Don’t bother with typos, misspellings, grammar, awkwardly-placed figures, and the like: those will all get changed later. I’m interested in two things:

1. Did the approach work for you? Did this chapter flow in a pleasing and sensible way? Is there information inexplicably missing?

2. Where did you get confused or stuck, in either the text or the “try this yourself” sections? Why? What would have helped?

Thanks.

Further announcements will probably go only to the mailing list.

Scott Finney has an interesting comment on my segment of the Naked Agilist podcast:

I listened to the Naked Agilists latest podcast the other day.

Brian Marick’s pitch in particular sparked my interest. He compares agile adoption against Geoffrey Moore’s technology adoption curve and observes a discrepancy; namely the seeming dearth of pragmatists. As I listened, a fundamental question immediately sprung to mind:

- Do we really have a case where the standard curve doesn’t fit, or
- Are we looking at the data incorrectly?

He suspects the latter. He may be right.

I’ve deferred work on Ruby Scripting for Leopard in favor of a new venture: a book on RubyCocoa. I had two reasons for doing that:

1. I’m unhappy with how difficult scripting is, not because of the scripting frameworks themselves, but because the apps’ interfaces are badly documented and buggy. A book documenting something that’s hard will sell less well than one documenting something easy.

   Is the bugginess going to change? Possibly, but the history of AppleScript doesn’t make me optimistic. However, this alone would not kill the book, or even defer it. But:

2. There are two competing scripting frameworks: rb-appscript and the Apple Scripting Bridge. I’ve been writing the same scripts in both. I have no particular opinion on their different approaches, but rb-appscript is more mature. I find myself using it first, then translating a script into Scripting Bridge.

   That’s a problem. If the book treats rb-appscript, whatever comes next after Leopard could conceivably do the same thing to rb-appscript as Time Machine is doing to backup software. But I just can’t convince myself that Scripting Bridge is ready for mainstream Rubyists. I could document both frameworks, but I can also wait and see how things shake out.

Sorry for the disappointment.

I’ll be announcing a review draft of the “How Do We Get This Thing Started?” chapter later this week at the book’s mailing list.

Kanban-inspired scheduling is the most interesting idea to come along in a while. Read the links above for a fuller description, but the short version is that there’s a fixed pipe of work items, where each is larger than a traditional story. (As I’ve noted before, small stories compensate for our inability to estimate by shifting work to the product director.) The larger work items, often called “minimum marketable features (MMFs)”, contribute a more satisfying chunk of business value than a small story can.

Rather than scheduling an iteration at the beginning, you just keep the pipe full. When one MMF is done, the product director puts the next one in.

It has an appealing simplicity, and I think it fits in well with Jeff Patton’s recent focus on not letting incremental development squeeze out iterative development. (Jeff thinks so too.)

What worries me is discipline. An iteration is a fairly firm commitment to produce X amount of value in Y amount of time. A MMF is, too, but there isn’t (as far as I understand) any moment when some defined set of MMFs is either done or not done. Their “lifetimes” always overlap. Since the people working on this are savvy, I’m sure they have ways for people to take stock of how they’re doing, whether they’re getting faster or slower, etc. I just don’t know what those ways are, and it’s the only thing keeping me from dipping my toe into the water.

Jason Gorman compares Scrum to a virus. He uses the example of a DNA virus that destroys the cells it infects. But it could be an endogenous retrovirus that infects the DNA of germ (reproductive) cells and thereby takes over an entire species. From an interesting New Yorker article:

It takes less than two per cent of our genome to create all the proteins necessary for us to live. Eight per cent, however, is composed of broken and disabled retroviruses, which, millions of years ago, managed to embed themselves in the DNA of our ancestors. They are called endogenous retroviruses, because once they infect the DNA of a species they become part of that species.

There is even some evidence that:

without endogenous retroviruses mammals might never have developed a placenta, which protects the fetus and gives it time to mature. That led to live birth, one of the hallmarks of our evolutionary success over birds, reptiles, and fish. Eggs cannot eliminate waste or draw the maternal nutrients required to develop the large brains that have made mammals so versatile. “These viruses made those changes possible,’’ Heidmann told me. “It is quite possible that, without them, human beings would still be laying eggs.”

So that kind of Scrum-as-a-virus could be a positive and enduring good (though there’s a lot of suffering amongst the “early adopters”).

I’ve made a video showing something of what it feels like to script a Mac application using Ruby. It also explains the basics of rb-appscript, one of the two main Ruby frameworks.

I made it after a burst of frustration with how often my scripting runs into wholly unnecessary snags. What I wish I knew is how many people who would love to script iTunes or Mail or whatever won’t because app developers make it too hard.

Perhaps I’ve stumbled into more snags than a normal human would (being a tester curses you that way). Or perhaps I overreact. Both seem to happen a lot. If you have experience with AppleScript or Ruby scripting, and you think so, let me know in comments or mail.

The video is 13 minutes long.

I’m pleased but surprised. I was lower than ideal on many questions. I’ve never even built a computer.

It’s even odder when you consider that the badge is wrong: I’m actually nerdier than 96% of people who took the test.

H/t Ron Jeffries, who is definitely more of a nerd than I am.

Kevin Rutherford:

Clarke Ching has now published the podcast of last Saturday’s Naked Agilists conference. You can download it by following the links from www.nakedagilists.com, or get it directly from Clarke’s blog. It’s a great 90 minutes of presentations and discussions, and the Naked Agilists website has links to the slides so you can follow the presentations along with the speakers.

We had five 10-minute presentations:

1. Servant Leaders — Nancy van Schooenderwoert
2. wevouchfor.org — Laurent Bossavit
3. Fit4Data — Adrian Mowat
4. Shared data for unit tests — Paul Wilson
5. Let them Eat Cake — Brian Marick

And after each little session we had 5-minutes of discussion and Q&A. Also taking part in these discussions were Clarke, who chaired the whole thing expertly, me, and Willem van den Ende, who helped put the show together (as did Brian Marick).

Join the Naked Agilists mailing list to find out when the next event will be — and help us find an inexpensive technology that will make it live and interactive!

Note: Nancy’s talk (the first) is hard to hear. Too bad.

In the Naked Agilist podcast (not posted yet), I reiterated a claim I made at the Functional Testing Tools workshop: that it’s a bad thing Agile has “crossed the chasm” and maybe a big chunk of us ought to cross back. Adrian Mowat writes sensibly about my outlandish claims on his new blog. I recommend his post, as he makes a strong case that (my interpretation) we’re failing both Moore’s visionaries and the conservatives.

As part of working up Ruby Scripting for Leopard, I need to write piles of scripts. If you have a script you’d like to see written, drop me a line. It needs to be a script that controls applications in either /Applications or /System/Library/CoreServices. The application should be one that’s pre-installed or one that most everyone should install anyway (e.g., Quicksilver). You have to be running OS X 1.5 (Leopard).