This is the cur­rent iter­a­tion of the Genetic Pro­gram­ming work­shop née Agile Team Dojo I’ve been work­ing on over the last few years.

I’m look­ing at the Michigan/​Ohio/​Indiana region for an inter­est­ing place to run it. If you’re inter­ested in sched­ul­ing me for a two– or three-​​day work­shop, feel free to con­tact me online.

You know how to do that.

The Mir­ror Dojo: Genetic Pro­gram­ming for Agile Teams

Genetic Pro­gram­ming has been actively researched and pro­moted for more than a quar­ter cen­tury. It’s a broad col­lec­tion of design prac­tices and mod­el­ing tech­niques for the “auto­matic” dis­cov­ery of abstract pat­terns and struc­tures.

And that means full-​​fledged pat­terns and struc­tures: algo­rithms, pre­dic­tive mod­els, com­plete mechan­i­cal and opti­cal and elec­tronic designs, and even blue-​​sky arti­fi­cial intel­li­gence systems.

Some of the field’s big hits include:

• the “auto­matic” redis­cov­ery of the basic rules of physics [PDF] from dig­i­tized video of exper­i­men­tal systems,
• the com­plete and “auto­matic” redesign of an antenna for a space probe,
• sys­tems that let robots “intro­spect” to find ways of walk­ing, even when seri­ously damaged,
• “auto­mated” stock trad­ing systems,
• patentable com­mer­cial ana­log cir­cuit and opti­cal designs,
• “auto­matic” design of backgam­mon play­ers [PDF], and
• “auto­matic” dis­cov­ery of code patches for real, work­ing soft­ware [PDF].

Sexy stuff! Nerds like us love it.

Bet­ter yet: I can describe all the basic design prin­ci­ples of Genetic Pro­gram­ming in four sen­tences. It’s so sim­ple to describe that I’m com­pletely con­fi­dent that I can help you you—a com­pe­tent soft­ware devel­oper work­ing on an agile team—write a work­ing GP sys­tem in an hour or so!

And that’s just what we’ll do in this two-​​day workshop.

But there’s one more thing.

You’ve prob­a­bly noticed that I always put extra-​​scary scare-​​quotes around “auto­matic” when­ever it comes up.

Dur­ing this dojo we’ll be approach­ing this mate­r­ial as an agile team. We’ll build at least two full-​​featured genetic pro­gram­ming sys­tems, and we’ll bump very quickly into those scare-​​quotes.

And that’s what this work­shop is about.

See, I’ve been work­ing in this field for most of 20 years. It turns out that even after all that time, there’s a large and trou­bling gap between the tuto­ri­als and demos of genetic pro­gram­ming, and suc­cess­ful problem-​​solving with GP. You can mea­sure that gap in terms of time, or com­pu­ta­tional resources, or expected qual­ity of results.

Sound famil­iar?

Much of the advanced aca­d­e­mic research being done today in Genetic Pro­gram­ming focuses on ways to increase the com­pu­ta­tional power, to bring more proces­sors and faster code to bear so that “auto­matic” problem-​​solving has a bet­ter “chance of suc­cess” on a com­plex problem.

Ah, look; more scare quotes.

See, in this work­shop we’re not advanced aca­d­e­mic researchers in Genetic Pro­gram­ming. We’re much bet­ter pre­pared than they are: we’re an agile team.

In the work­shop we’re going to be explor­ing how to tell our lit­tle arti­fi­cial “team” of “auto­matic devel­op­ers” what it is we want, and how they should go about mak­ing it for us, and (because GP just works) they’ll be “releas­ing soft­ware” for us. What we’ll be doing is design­ing the rules by which they solve our prob­lem: espe­cially the ones that spell out how we want them to inter­act with one another.

Which should explain the name of this dojo. And maybe even why it will take lit­tle bit longer and a bit more effort than most oth­ers you’ll run into.

Scope: This is a two– or three-​​day work­shop, for three to eight soft­ware devel­op­ers, engi­neers, coaches, design­ers, sci­en­tists, and other nerds.

The major­ity of par­tic­i­pants should be famil­iar with com­mon platform-​​agnostic pro­gram­ming lan­guages (Ruby, Python, Java, Smalltalk). They should be com­fort­able work­ing in an agile team: we’ll col­lec­tively work in one shared pro­gram­ming lan­guage, and rely on auto­mated unit and accep­tance tests, rapid release sched­ules, agile plan­ning, and pair pro­gram­ming. There should be enough lap­tops for every pair to code, and net­work con­nec­tiv­ity enough to use github for ver­sion con­trol and coordination.

On the first day of the work­shop (6 hours plus lunch) we’ll estab­lish the social infra­struc­ture, and imple­ment a sim­ple but full-​​scale genetic pro­gram­ming sys­tem for sym­bolic regres­sion. At the end of the day, we’ll choose an advanced project for the next day.

Because we’re all nerds, you and I both know you can’t “stop work­ing” after just five or six hours—and that’s fine. But the work day for the project is six hours plus lunch. So no com­mits overnight!

On the sec­ond day (6 hours plus lunch) , we’ll use genetic pro­gram­ming to address a tech­ni­cal prob­lem where results are obvi­ously practical—and prob­a­bly pub­lish­able.

In three-​​day work­shops, the final day can be used (at the team’s dis­cre­tion) for either refine­ment and pub­lic release of tan­gi­ble prod­uct from the prior days, or for a third project using dif­fer­ent GP design patterns.

Why?: The dojo is just what it says: an expo­sure for agile soft­ware devel­op­ers to a sexy but poorly-​​understood tech­ni­cal prac­tice with great eco­nomic poten­tial in the com­ing years. At the same time they’re learn­ing about the tech, they’ll be sur­fac­ing aspects of their own work, and the way agile prac­tices mold project man­age­ment in the “real world”: require­ments, goal-​​settings, information-​​sharing, met­rics, col­lab­o­ra­tion pat­terns, infra­struc­ture, deliv­ery sched­ules, and even the juris­dic­tion of man­age­ment vs. developers.

Cost: The most impor­tant cost for this exer­cise is the par­tic­i­pants’ inter­est and atten­tion. If those have been made avail­able, the only finan­cial costs are for the venue, travel, food and board (where needed) for the participants.