I’m think­ing this will want to be two or three con­sec­u­tive weeks of our Ann Arbor-​​based Tues­day evening “Crafts­man Guild” meet­ing, but I could be con­vinced to run it on a cou­ple of con­sec­u­tive week­ends, as well. The gaps in between ses­sions are actu­ally use­ful, since I think they give folks a chance to think about stuff that should be both­er­ing them as we proceed.

Devel­op­ing an awe­some Genetic Pro­gram­ming sys­tem… from scratch

The Point:

We often run these agile cod­ing exer­cises as if user sto­ries and accep­tance tests drop from the sky. In real projects, they’re typ­i­cally the biggest source of con­fu­sion and pain—even in projects we’re work­ing on by our­selves. The sub­ject mat­ter we’ll explore here, Genetic Pro­gram­ming, is hugely sexy, tech­ni­cally sim­ple, and offers only triv­ial cod­ing challenges.

You might won­der why so few peo­ple use it, then, after 20 years. Why it hasn’t changed the world and made arti­fi­cial intel­li­gence part of our every­day lives.

The answers to those ques­tions have noth­ing to do with the computer.

The Struc­ture:

Two or three ses­sions, each about 2 hours.

We’ll run the ses­sions in a Cod­ing­Dojo for­mat, much like the “cod­ing ran­dori” we’ve seen in ear­lier Crafts­man­Guild meet­ings, where there’s one “dri­ver” and one “nav­i­ga­tor” pair­ing on a lap­top con­nected to a pro­jec­tor, with the entire “audi­ence” help­ing them along the way as they write code (and do chores).

If it seems prac­ti­cal in a later ses­sion, we may split into two teams (still with one cus­tomer and one project).

I’ll role-​​play “the cus­tomer rep­re­sen­ta­tive” for a cus­tomer who’s off-​​site, with the rest of the group act­ing as “the dev team”.

In addi­tion to the cod­ing com­puter, we’ll set up a pro­jec­tor up show­ing a live Piv­otal­Tracker instance where we can col­lect, sort and make progress on sto­ries as an inte­gral part of the devel­op­ment process.

Dur­ing the first iter­a­tion we’ll decide on lan­guage and infra­struc­ture, based on who’s there and what they want and know.

As code is writ­ten it’ll be com­mit­ted to the github project (so the audi­ence can fork it and work along), but we’ll have for­mal review ses­sions with “the cus­tomer” accept­ing or declin­ing par­tic­u­lar solu­tions after every iter­a­tion, look­ing at the sto­ries we worked on and gath­er­ing new ones as they crop up.

Par­tic­i­pants:

…should have used some mod­ern test­ing frame­work, but they don’t need to be experts (or evan­ge­lists) at either TDD or BDD. They should be com­fort­able, but don’t need to be flu­ent, in at least one mod­ern pro­gram­ming lan­guage like Java, Ruby, Python, &c. They should at least have looked at piv​otal​tracker​.com to famil­iar­ize them­selves with the fea­ture set and story-​​sorting idiom.

The lan­guage we pick should be the one which most par­tic­i­pants are most com­fort­able using when they do real work. What­ever lan­guage and infra­struc­ture we decide on, it shouldn’t be an obsta­cle to take a sim­ple user story like “Adding two num­bers together should return their sum” and actu­ally write the accep­tance test, and then run it.

The Project:

The Customer’s over­all goal is to build a Genetic Pro­gram­ming sys­tem that can accept a set of data, a set of math­e­mat­i­cal prim­i­tives, and will evolve math­e­mat­i­cal equa­tions of the form that fit the data. Here’s an (antique!) Java applet that does some­thing along those lines already.

This sort of GP project typ­i­cally breaks down into five chunks:

• build a sim­ple but full-​​featured inter­preter for a domain-​​specific lan­guage (DSL) intended for math­e­mat­i­cal modeling
• build an eval­u­a­tor that deter­mines how well an arbi­trary DSL script matches tar­get data
• write meth­ods to cre­ate ran­dom pro­grams, and also mutate and cross over DSL scripts
• build a sim­ple sym­bolic regres­sion sys­tem that fits numer­i­cal data with arbi­trary math­e­mat­i­cal models
• adapt to some minor prob­lems that may arise along the way

These may sound like big, ambi­tious steps, but in fact they’re all tech­ni­cally simple.

The goal of the dojo is not to learn to type some­thing quickly or get as much done as pos­si­ble.

It’s designed so we adapt the emerg­ing code­base and our col­lec­tive under­stand­ing of the prob­lem the cus­tomer is ask­ing for, in a con­text where there are no “tricks” (I won’t be lying to you, except maybe by omis­sion), but where there are plenty of traps.