Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
191.8 167.2 186.2 183.6 184.0 183.2 184.6

Tue, 31 Jan 2006

OOPSLA Essays 2006

Last year, I was track chair for the OOPSLA essays track. This year, thankfully, it's Richard P. Gabriel, who will be more successful than I was. I'm on the committee. A quote from the track page:

An essay is a rigorously peer-reviewed reflection on technology, its relation to human endeavors, or its philosophical, sociological, psychological, historical, or anthropological underpinnings. An essay can be an exploration of technology, its impacts, 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.

What makes for a successful essay? At its best, an essay is a clear and compelling piece of writing that enacts or reveals the process of understanding or exploring a topic important to the OOPSLA community. It may or may not have a conclusion, but it must provide some insight or argument. A successful essay shows a keen mind coming to grips with a tough or intriguing problem; as Virginia Woolf wrote, "it explains much and tells much." [from the preface of "Memoirs of a Working Woman's Guild"].

The idea of essays is one of those oddities that have made OOPSLA so interesting and productive over the years. You should submit. By March 18.

## Posted at 06:01 in category /oopsla [permalink] [top]

Mon, 10 Jan 2005

OOPSLA call for papers is out

The OOPSLA Call for Papers is out. I'm chair of the Essays track. Here's its blurb:

Some ideas are the result of research and others of reflection. Sometimes it takes someone sitting down and just thinking about how things are connected, what a result really means, and how the world really is. Some of the most impressive products of civilization are its essays - philosophy, for example, is reflection captured in essays. An essay presents a personal view of what is, explores a terrain, or leads the reader in an act of discovery. Some contributions to computing come in the form of philosophical digressions or deep analysis. An essay captures all these - one at a time or all at once.

Each essay will be afforded a 45-minute speaking slot and allocated about 20 pages in the proceedings.

I've assembled a wide-ranging committee: a business school professor, head of the MIT AI lab, head of the Illinois sociology department, professors of philosophy, sociology (again), and statistics, a Forrester researcher, a Pragmatic Programmer, the director of the Warren-Wilson Master of Fine Arts program, another software consultant, and me.

As that list implies, we're looking for submissions from both those within the software fold and those outside it. Spread the word, please.

See also this:

Submissions are due March 18.

## Posted at 14:25 in category /oopsla [permalink] [top]

Sat, 06 Nov 2004

That ol' "n degrees of separation" thing

When you're asking people to do work for you, especially unpaid work, it helps a lot if you already have a personal relationship. In staffing next year's OOPSLA essays track, I want to find committee members who are well known, interdisciplinary, and like novelty and change. I know some - never enough - people like that in software, but I know fewer outside software. So I'm going to do something quirky: diffuse invitations through a network. Here's how:

  1. On one of my unused wikis, I've placed a list of people who I think would fit well with our plans and might find the opportunity interesting or even useful. (Right now, they're Malcolm Gladwell, Rodney Brooks, Lucy Suchman, Etienne Wenger, Corey Doctorow, Lawrence Lessig, Edward Felton, and Eszter Hargittai.)

  2. If you (a) know someone who is more likely to know the person named than you are, and (b) think that intermediate person would find the idea of the essays track interesting enough to forward it on, send them the text you find here.

  3. But incorrigible optimist that I am (heh!), I'm afraid of a sorcerer's apprentice situation. I don't want intermediate people or the final recipient to get an annoying amount of email. So before you send mail headed for a particular person, check if four people already have. If four people have, don't send mail. Otherwise, do send mail and leave a note on the wiki.

  4. If you know one of the targeted people, contact me so that we can arrange an introduction.

Thanks. Let's see what happens...

## Posted at 14:37 in category /oopsla [permalink] [top]

Mon, 01 Nov 2004

OOPSLA essays track

The program chair for OOPSLA 2005, Richard P. Gabriel, wants to shake things up. As part of that he's going to institute an Essays track, and I will be program chair for that track. I'm hunting for people to serve on the committee.

The essays don't have to be original research, the usual OOPSLA fare. Instead, they'll be of two types.

  • Richard describes one as "the first draft of your Turing Award lecture". The Turing Award, as the highest honor in computer science, comes with the obligation to produce a speech, usually of the sweeping nature expected from an elder in the field. We're looking for essays of that sort: a survey of breadth and experience, telling the field something about itself, making tacit assumptions and habits explicit.

  • Essays from outsiders who are deeply experienced in a different field, have some knowledge of ours, and can come to us and say, "It's so odd that you do X, because we in field Y do that sort of thing completely differently". These essays should shake us out of our ruts.

To that end, I'd like to get committee members from both inside and outside the field. When they come from inside, I'd like them to have serious knowledge of some outside field. I welcome suggestions.

## Posted at 09:38 in category /oopsla [permalink] [top]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.

 

Syndication

 

Agile Testing Directions
Introduction
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects
Postscript

Permalink to this list

 

Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list

 

Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI

 

Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."

 

Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich

 

Where to Find Me


Software Practice Advancement

 

Archives
All of 2006
All of 2005
All of 2004
All of 2003

 

Join!

Agile Alliance Logo