January 2009 Archives

I'm giving a short talk to the University of Washington iGEM interest group tonight based on my experience watching the competition from the beginning and as a judge for the last couple of years.

The judges are given a long list of criteria for the various medals and awards.  The list has grown longer and more involved -- if the trend holds next year I expect it to be even more complicated.  There are many more teams than judges, so each of us sees only a small fraction of the teams in person on the first day of the Jamboree.  The only way we can keep things fair (and keep the teams straight in our heads) is to follow the judging criteria very closely.  We have a checklist.

It is important to remember in what follows that my academic training is in experimental physics, and I spend most of my time today trying to build stuff out of DNA.  I don't have anything against elegant and cool models; I simply groove more on elegant and cool atoms.  I speak only for myself and not for any other of the judges or organizers.

Here is what I plan to say this evening:

1. You need to make easy for the judges to understand your objective and your design.
2. Web pages can be too cool.  A rough rule of thumb: the cooler the web page is, the harder it is to understand.  A cool web page may be full of information, but as a judge it is the baud rate I care about.
3. Fun is good.  Demonstrating actual learning is better.  Data trumps everything.
4. In my experience, the more equations in your model, the less likely you will produce experimental data.  I find complexity as distracting in my own work as I do when I have something like 15 minutes to figure out the theoretical details of an iGEM project.  Keep it simple!
5. Find a mentor to help tailor your story to your customers, namely the judges.  This past year the judges were a mixture of academics and industry types -- biologists, engineers, computer scientists, physicists; theorists, experimentalists, hackers.  All probably have PhDs in something or other, which means we are used to rapidly parsing stories that are packaged more like papers in Science and Nature than like facespace/mybook/twitterwikirama/whatever.  Those things may be the future of science for all I know, but your customers (the judges) don't play that game -- we are fogeys as far as you are concerned.  You have to market to us.
6. Follow the directions!  Follow the checklist.  Make sure your DNA is to spec (e.g. meets the Biobrick(TM) standards).  Make sure it is in the Registry.  Get everything in on time.  Sometimes the organizers and judges screw up this part -- the way to resolve complaints is with reason and your own checklist.  No whinging.
7. Here is a suggestion I made to the organizers after the last competition.  Even if they don't implement it, you should.  Everyone in the competition has completed some sort of laboratory course requiring basic experimental write-ups.  Make sure your web page has a basic lab write-up, no clicking or hunting required. You will do better if the judges don't have to spend even thirty seconds trying to figure out if you have actual data and where it might be hiding on your wiki, especially if other pages are better designed and easier to read.  If I recall from my student days, those write-ups go something like this, mostly in this order: "1. Here is what we wanted to do and why.  2. Here is what we did.  3. Model.  4. Data.  5. Conclusion."  Bonus: if it didn't work, why not?  iGEM and the Biobricks Foudation both need a failure archive.
   

Good luck next year!

(Update, 30 April 2009: I see from the server logs that this post is getting a lot of traffic today.  Please note that the contents of the post discuss the annual influenza strains in the US, not the "H1N1 Influenza A" strain, which at this time is susceptible to Tamiflu.)

The IHT is carrying a great article by Donald Mcneil on the sudden emergence of antiviral resistance in this year's circulating influenza viruses.  The title says it all: "Flu in U.S. found resistant to main antiviral drug".

Virtually all the flu in the United States this season is resistant to the leading antiviral drug Tamiflu...  The problem is not yet a public health crisis because this has been a below-average flu season so far and the chief strain circulating is still susceptible to other drugs.

There are two important points in this story.  First, the resistance seems to derive from a spontaneous mutation rather than having emerged from overuse of the drug:

"It's quite shocking," said Dr. Kent Sepkowitz, director of infection control at Memorial Sloan-Kettering Cancer Center in New York. "We've never lost an antimicrobial this fast. It blew me away."

The mutation appears to have arisen in Norway, a country that the article suggests does not even use Tamiflu. Second, while the CDC is recommending that hospitals test all flu cases to find out whether patients are carrying a the resistant subtype, this capability is still not widespread:

"We're a fancy hospital, and we can't even do the ... test in a timely fashion," Sepkowitz said. "I have no idea what a doctor in an unfancy office without that lab backup can do."

I haven't written very much about the flu for a couple of years, but it is clear that the threat is still quite present.

The article ends with this bit of speculation:

And while seasonal flu is relatively mild, the Tamiflu resistance could transfer onto the H5N1 bird flu circulating in Asia and Egypt, which has killed millions of birds and about 250 people since 2003. Although H5N1 has not turned into a pandemic strain, as many experts recently feared it would, it still could -- and Tamiflu resistance in that case would be a disaster.

I'm not so sure that the resistance gene "could easily transfer onto the H5N1 bird flu".  It sounds like Mr. Mcneil may be giving more weight here to Henry Niman (who is quoted extensively in the article on other specific topics) than the rest of the community might.  This is not to say that such a transfer is unlikely -- this is the sort of thing that I fear we know so little about that we could make poor assumptions leading to even worse policy.  The mechanisms for recombination and reassortment of genes in the flu are still disputed in the literature.  But it's damn scary, either way, even if the probability of such a transfer is small.

In the end, if nothing else, what this demonstrates is that our technological base for both detecting and responding to infectious disease is still poorly developed.

Carl Zimmer has a nice piece in Yale Enivronment360 on continued efforts to build bugs that produce fuel, "The High-Tech Search For A Cleaner Biofuel Alternative".  The article extensively quotes Steve Aldrich, President of Bio-era, on the trade-offs of using sugar cane as a source material.

Craig Venter makes an appearance arguing that the best long-term bet is to build photosynthetic bugs that use atomspheric CO2 to directly produce fuel.  Maybe.  This would require containment facilities for culturing engineered bugs, where those facilities also must capture sunlight and CO2 to feed the bugs.  The costs for this infrastructure are not insignificant, and this is exactly what is presently standing in the way of large scale algal biodiesel production.

Here is the question I keep asking in these circles: why not just grow naturally occurring algae, which can be grown at extremely high yield in a wide variety of conditions, as food for bugs hacked to eat cellulose?  If there is no algae to be had, just throw in another source of cellulose or other biomass.  There would be minimal concern over growing modified organisms that might escape into the wild.  The processing of biomass into fuel under would also be under conditions that are easier to optimize and control.

I'm not suggesting this is the only answer, but rather that it appears to balance 1) the costs of infrastructure, 2) concerns over enviromental release of genetically modified organisms, and 3) provide an efficient processing infrastructure that could use a wide variety of feedstocks.