I find that I have a stack of four or five small research projects that have come up (in the sense of “I wonder what would happen if…oh, right, that would be cool”) over the last seven weeks. Any one of them would involve about 40 person-hours of work: a very small amount of up-front analysis and design, some (apparently) minor programming to enhance or extend pre-existing evolutionary and/or simulation frameworks that are publicly available, some data collection and analysis, some writing. Any one of them would result in 1 or 2 posters for sure, with an additional 1-2 conference talks and papers available through a bit (20%?) of extra effort.

Yet here I sit, merely a first-year graduate student, with classes and crap to do. I don’t have time to do all of it, let alone my real homework. Which is a sin. So I want somebody to do it with me, where “with” is a nuanced version of “for” with a heavy dose of friendly collegiality. I want to be, in the parlance of the agile software development people, the customer on these projects, and that means I need to be involved at least as much on the team doing the work as any one of them is.

I say that last, making sure to point out I mean “customer in the sense of agile software development”, because I know how scary and weird and offensive this whole notion is going to sound. It will sound like I’m invoking “milestones” and acting the role of some pointy-haired boss who wants to bring the True Light of Six Sigma — no: Seven Sigma! — to the stupid, wasteful laboratory and mess with and ruin the Way Things Are. And that’s wrong, I assure you: I wear a buzzcut these days.

No, really. It’s very short.^*

See, I am surrounded at work by very bright people who are forced to do very dumb things with their time and attention. They are busy, all the time, because they are all forced (or choose) at every turn to do every bit of every project they themselves have thought of. The culture demands it: These people need to program and do lab experiments for themselves (which is a poor use of their time, and tends to result in substandard code/data and untrustworthy results). If they are not programming and doing lab experiments for themselves, they are expected to employ green, inexperienced people and pay them a pittance to learn on the job (which “sink or swim” approach has scant pedagogic value if any, and tends to result in substandard code/data and untrustworthy results). They are often left to play a cowboyish “exploratory” game with their projects, in which they fart around with things and undertake little experiments with no acceptance criteria or thought of when they will know they’re done, or what they will do with promising leads they have no resources to follow up on (which is often a waste of their funding, and tends to result &c &c). And they need to keep their cards to close to their chests, so their “competitors” cannot “steal” their ideas and grab all the credit, so they work in relative isolation until they are “ready” to publish their work (which &c &c).

And you know what? I can’t give away good ideas in such a place. Not only is there no venue for doing so: there is no audience. Nineteen times out of twenty, you tell somebody something, and they nod and say “that’s interesting” — even when they’re replicating long-known work from some other discipline — and carry on as before.

Some research projects I’ve heard about recently make me think of Tibetan prayer wheels: only by repeating the same research over and over in every discipline, one at a time, without cross-reference, can the benevolent attention of Truth come to all disciplines in turn. Either that, or plain copying is low-hanging fruit….

These will be familiar tropes to long-term readers, who should be bored out of their patient skulls by now. And now I want to do something about it.

So, here’s a stab, with one project I want to do right now:

Hey folks, we’re forming a band (of researchers)!
Want to do way-cool bleeding edge engineering and science, live and in public? Wanted: Two or three smart folks, at least two familiar with C++, for a quick suite of experiments involving the genetic programming of optimization algorithms, probably using the PushGP and Pushpop systems for automatic code generation. The project will be run at least a little bit “agile”, meaning we will have frequent quick and to the point meetings online, we will obey 100% shared ownership of all code, will stress unit and acceptance tests (and will discover what that implies in a research setting), and try at every turn to make sure that the stuff we’re doing brings us as close as possible to the thing we want. I expect it will take somewhere on the scale of 40-50 hours overall (from everybody) over a period of three months, for which trouble we will all get to be coauthors on all derived papers and blog entries. You need not be an academic researcher or domain specialist to apply, but should be comfortable with a development environment that’ll work C++. R language skills a plus! But don’t plan on keeping the project, process or results a secret. Everything will be transparent and available for public comment.

And at the same time, we’ll be trying to discover a useful and formal agile research methodology.