Exploration Through Example

I’ve long hated the sentence in the title, for a number of reasons. I threw away a long blog post about that yesterday, but let me just issue this challenge. How do the meanings of these three sentences differ?

Quality is value to some person.
Quality is quality to some person.
Value is value to some person.

I’ve altered and made more specific the idea behind Travels in Software. People without experience can’t get by with only facts: they need stories. Stories teach them values—habits and reactions they can put to use when they have a thorny dilemma. Stories also give them a mental picture of an achievable way of working. People can say, “What we’re doing here just doesn’t feel right. Story planning [or test-driven design, or standups] seemed so smooth in that story. Let’s move toward that way of working.”

So the book will be largely made up of stories told by people who are proud of their work, their team, how they handled some problem or seized some opportunity. The stories will describe how to be or become a team that works with ease.

I plan to present these stories as oral histories. I’ll record people, ask questions, help them tell their story, then edit the story down—removing my promptings, any redundancies or un-useful digressions. The goal is to produce the most compelling possible version of the teller’s words. My model is Studs Terkel. (To see this style, look inside Hard Times.)

I’ll post the stories in a blog. In the book version, stories or groups of stories will be preceded or followed by explanatory text and essays on the topics covered.

The first interview is tomorrow. For now, I plan to conduct them in person. Mail me if you have a story to tell.

A message from Richard P. Gabriel:

Folks:

Writing papers is fun, but we don’t get to stretch our wings too often. Here is an opportunity to write something in a totally different style:

Submit an essay to Onward! Essays
Deadline: 20 April 2009

An Onward! essay is a thoughtful reflection upon software-related technology. Its goal is to help the reader to share a new insight, engage with an argument, or wrestle with a dilemma.

A successful essay is a clear and compelling piece of writing that explores a topic important to the software community. The subject area should be interpreted broadly, including the relationship of software to human endeavors, or its philosophical, sociological, psychological, historical, or anthropological underpinnings. An essay can be an exploration of its topic, its impact, or the circumstances of its creation; it can present a personal view of what is, explore a terrain, or lead the reader in an act of discovery; it can be a philosophical digression or a deep analysis. It can describe a personal journey, perhaps that by which the author reached an understanding of such a topic.

I’m the assistant program chair (Simon Peyton-Jones is the chair), and I’d love to get submissions from the agile community. Reflections on
how to create software, what the creative process is like for software, what extremes of process could work in the future, where else could agile work, has it worked,… you name it. Anything to do with software.

NB: Onward! is co-located with OOPSLA, but they are otherwise unrelated. OO is fine, but not required. Not even encouraged.

Don’t forget: 20th April.

PS: To get your imagination going, here are a couple of (strongly contrasting) past essays:

* Dan Grossman “The transactional memory / garbage collection analogy”

* Dick Gabriel “Designed as designer”

* Friedrich Steimann “The paradoxical success of aspect-oriented programming”

or pick up your favorite essayist - be it Samuel Johnson (it’s his 300th birthday!), John McPhee, David Foster Wallace (my favorite), William T. Vollman, Edsger Dijkstra (ugh), or, what the hell, Richard P. Gabriel - and get inspired.

Someone asked me for advice on how to get invited to speak at conferences. Key advice:

• become a valuable participant in a niche field,
• grow along with the niche,
• become a good speaker.

I’ll cover the first two in this note. The details are somewhat particular to my personality and the lucky breaks that came my way. But some of them would work for other people.
(more…)

I will be driving this route sometime in late February to early March:

I have to be in Salt Lake City for MountainWest RubyConf on March 13-14. I have no fixed departure date. That’s because I want to do some visiting along the way. I may also do some visiting on the way back.

I have a half-formed plan to use such trips to do research for a book, tentatively titled Travels in Software: What the Great Teams Know. I want to find teams that are special in some way that other teams ought to learn from. It could be that they are particularly good at some specific technique, or that they have a general style that deserves emulation, or that they’re notably long-lived. (I mention the latter because I’ve gotten interested in the idea of “resilient teams”: ones that don’t dissolve because people get bored with what they’re doing, have survived big changes in their corporate environment, etc.)

If you are such a team, let me know.

My idea for a visit would be to “embed” myself in a team for up to a week. I would work with people on the team, pitching in on whatever they’d be doing were I not there. I’d also consume some time interviewing people.

Someone with authority would have to sign a Disclosure Agreement beforehand. Roughly, you’ll have to agree that you have no control over what I write about how you do things, but you can have reasonable control over descriptions of what you’re doing those things to. If you don’t want me to describe the product or your super-duper, soon-to-be-patented algorithms, that’s fine.

I forgot to mention that I did a podcast with Daniel Steinberg:

Brian Marick on Ruby Cocoa and Testing
Who’s smart enough to program?

Brian Marick talks to Daniel Steinberg on a wide variety of topics. Brian asks, who’s smart enough to program?, and describes how he met Andy and Dave at the Agile Manifesto summit. He talks about using Lisp, Smalltalk and Ruby, and about introducing programming to testers. Brian also shares the secrets of Domain Specific Languages (DSLs), and of course, his new book on Ruby Cocoa: marrying Ruby with the uber-cool Mac OS X Cocoa GUI framework, and test driven development with Ruby Cocoa code.

The Pragmatic Bookshelf has other podcasts, too.

UPDATE: Turns out that what I want to do, modeled after something used for RubyConf, can’t be done in stock Twitter. Seeing if I can persuade the Twitter people to work the same magic for me.

Item: Richard P. Gabriel has this habit of making software people write or speak within artificial constraints.

• For writers’ workshops (book-length PDF), he’s made reviewers write a summary exactly 29 words long.

• In last OOPSLA’s “50 in 50” keynote, he and Guy Steele, Jr., covered the last five decades of programming languages in 50 segments, each exactly 50 words long (in a talk lasting, I believe, about 50 minutes).

The point of constraints is that they make you work: you can’t use the words that first come to mind. You have to struggle to say what you want while playing by the rules them—and sometimes that makes you realize you ought to be wanting to say something else. Constraints are a tool to make you think new thoughts.

Item: I’ve become strangely fond of Twitter. It’s a service that lets you send short (140 character) “tweets” out into the ether. Other people can subscribe to (”follow”) your tweets. They can see the tweets of everyone they follow by visiting their own twitter web page (here’s mine), subscribing to an RSS feed, or using a twitter-specific app to fetch tweets. (I use Twitterrific.)

That’s form: what about content? As Twitter user shalunov (Stanislav Shalunov) puts it (in a tweet):

Four main ways to tweet: ideas, news, @-chat, phatic coffee. The last is the original, rest invented by users.

Ideas are the tweets I’m most interested in. Slalunov’s is an example of an idea tweet.

News is my second interest. As a geographically isolated person, it’s one way of knowing what interesting people are chattering about.

• bilkleb, for example, is fond of linking to both technical topics (“heard Paul Tuckfield talk about scaling YouTube MySQL, “mirror disk drives in hardware, stripe in software.” (http://tinyurl.com/277dvy)”, “watching Matz’s Google Talk: http://tinyurl.com/3bzbuu“) and not-technical ones (“@barbjordan http://kluster.com looks interesting.”)

• Twitter’s also a good way for me to learn about new and interesting apps for the Mac.

• …and I follow lrz because he’s Apple’s Ruby guy, so what he does will affect my next book.

• …and there’s also the quick links to the absurd and humorous that’ve been around since the beginning of the web, like this from andytinkham: “This is just wrong, wrong, wrong (on so many levels): http://tinyurl.com/2zjpz5“ or this from objo: “hilarious http://rubyurl.com/DdyJ (via @timbray)”.

“@-chat” is a sort of person-to-person instant messaging. For example, cypher23 wrote “Stalker is a weird and wonderful film.” I replied: “@cypher23 Harrison’s new _Nova Swing_ is in the sub-sub-genre with Stalker, _Rogue Moon_, and _Roadside Picnic_. Liking it so far.” Anyone following cypher23 would see both his tweet and my reply. Someone following only me would see only my reply (but could click on the hyperlinked cypher23 to see all his recent tweets). Because of the one-sidedness, and because the topics tend to be less interesting than those in the first two categories, I tend not to follow people who have a high proportion of @-chat in their tweets.

“Phatic coffee” is just tweeting what you’re doing now, like avibryant’s recent “obsessively refreshing UPS tracking page for new laptop” Although I’m somewhat of a hermit and not much for social chit-chat, I’m not immune to phaticality. (I find chadfowler’s heavily phatic tweets appealing, oddly puckish, and somehow soothing.) But I likely won’t follow someone who’s predominantly phatic.

Item: While writing a book, I often find myself disinclined to spend spare time writing blog posts. Yet I continue to have ideas. I’m sure lots of other people do too.

Synthesis: I’ve created a fake twitter user named pithysoft. It’s for anyone’s pithy tweets about software development. When I finish this post, I’ll send the first one: “d pithysoft Business-facing tests are like personal ads: No matter how exact your description, the reality always tells you something new.” People following pithysoft will see it. If the pithy claim intrigues them, they can tweet pithysoft with something like “@marick More about tests and personal ads, plz”. That would encourage me to write it up on my blog. When I did that, I could tweet “@pithysoft Expanded on XYX here: XYX”

An experiment. Let’s see how it goes.

There’s a style of writing about software that’s bugged me for a long time. It’s what I call the “Joe burst into the room” style because it often starts with a sentence something like that. It’s a little morality fable in which a point about software development is made largely through a conversation between pairs of people.

I have two problems with the style:
(more…)

• Can you describe your audience? I used to ask the question in terms of types of reader - manager, tester, team lead, etc. - nowadays I might ask the author to describe a typical reader as a person rather than a role (as a persona, if you will).

• When a reader finishes your article, she should know more. But that’s not enough. Knowledge has to be put into practice. How will she do that? Will she know the first step to take? What, in the first few months after publication, do you want 1000 of your readers to have accomplished?

• When she puts your idea into practice, what beginner mistakes will the reader make?

• In what situations is your advice the wrong advice? When does your favorite tool/method/technique not apply? (”When people aren’t trained well enough” or “when there’s insufficient management support” almost always mean you haven’t thought things through well enough: there must be cases where your pet idea would be bad advice even for the best trained, best supported people.)

• How is your article different than the other hundred articles on the same topic?

See also hints for revising and this extra hint.