Exploration Through Example

There’s an interview with me at InfoQ. It covers micro-scale retro-futurist anarcho-syndicalism and my hypothesis that we could chisel value away from automating business-facing examples and add it to cheaper activities.

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.

You’re more likely to be invited to speak if you’re a good speaker. For the most part, I have the same advice you’ll find at places like Presentation Zen: avoid bullet points, etc. I have some idiosyncratic habits, though. They’re after the jump.

As with the previous entry, a disclaimer: the way I present is driven by my personality and background. I don’t claim any universal goodness for it.
Read the rest of this entry »

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.
Read the rest of this entry »

Here’s a metaphor I use a lot. Let’s assume we’re doing some sort of process where some people (call them “testers”) provide examples that another set of people (call them “programmers”) realize. By “realize”, I mean they change the code so that the examples, which were previously examples of something the product doesn’t do, become examples of something it does.

Most often, there are more programmers than testers.

What I tell teams is that I visualize the programmers as many baby birds in a nest, all chirping “feed me! feed me!” What they need to be fed with are examples to realize. The testers are the harried parent birds, zooming up to the nest, dropping a grub (a test) into a programmer’s mouth, then zooming off in search of another grub because—oh no!—another baby is about to finish its meal.

I tell this story for two reasons:

• It captures how harried testers (and product owners) can be on a team. It encourages the programmers to have a little sympathy.

• Just as the parent birds don’t stockpile all the grubs they’ll ever need in advance, the testers don’t have to have all the tests for a story done before delivering the first one or first few to the programmers. As long as the next test is there when the programmer needs it, all is well. In fact, finishing the next test just as the programmer finishes making the last one pass might be most efficient.

It’s just a metaphor, and has some imperfections. For example, there’s more to it than dropping tests onto programmers’ laps. There’s also discussion of what the whole story’s about, etc.

Photo by Flickr user aaroneus. Some rights reserved.

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.

MountainWest RubyConf in Salt Lake City, March 13-14, speaking on “Test-Driving GUIs (with RubyCocoa)”

Philly Emerging Tech in (wait for it…) Philadelphia, March 26-27, speaking on “Exhibitionism in Software Development”.

Mock object seem to require more whole-product (or otherwise large-scale) automated tests. I’m hoping not, especially if manual exploratory has some tool support. My reasons are below the jump.

Read the rest of this entry »

I saw a show on television, probably in the early seventies, that I think warped me forever. I’d like to see it again, but I remember only a few things about it.

I believe it involved a person who was inside a room that was made of glass panels. At some point, he/she had a conversation with a man who had a hammer. The man moved the hammer from one place to another and claimed it never occupied the space between. After that someone threw something - the hammer, I believe - through one of the panels, making a jagged hole. The man with the hammer looked up the shape of the hole in a book. It matched exactly one of the pages, and he said something like “Ah, hole 323″. I think he then got piece 323, and slipped it in to fix the hole.

If you know of this show, please contact me.

Another show that warped me at age 14 was Steambath, though I suspect it was much less weird.

If you create a subclass C inside a module M, the result is two distinct classes: M::C (as expected) and OSX::C (an unpleasant surprise):

require ‘osx/cocoa‘
puts OSX.const_defined?(’Squiggle‘)    # => false

module M
  class Squiggle <  OSX::NSObject
  end
end

puts OSX.const_defined?(’Squiggle‘)    # => true ?!
puts M.const_get(’Squiggle‘)           # => M::Squiggle
puts OSX.const_get(’Squiggle‘)         # => OSX::Squiggle
puts M::Squiggle == OSX::Squiggle      # => false
puts M::Squiggle.object_id
puts OSX::Squiggle.object_id

RubyCocoa 0.13.1, OSX 10.5.5

I believe this is because Objective-C doesn’t “get” separate namespaces - all classes are in the same namespace, which is why you can’t do this:

irb(main):001:0> module Second; class Quux < OSX::NSObject; end; end
=> nil
irb(main):002:0> module Second; class Quux < OSX::NSObject; end; end
/System/Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/
objc/oc_import.rb:266: warning: Cannot create Objective-C class for
Ruby class `Quux', because another class is already registered in
Objective-C with the same name. Using the existing class instead for
the Ruby class representation.
objc[12661]: objc_registerClassPair: class 'Quux' was already registered!