Admit it: you have a “lucky” PCR machine, don’t you?
As any experimental biologist can tell you, working at the bench has a strong element of tradition and muscle knowledge. If I’m running a Western blot or pouring a gel, I’ll probably do it a certain way, because that’s the way I was taught, back when I was a fresh-faced young undergraduate, and it’s always worked for me. If the reviewers are happy, I’m happy. But is this the best a scientist can do? Could bench practice be more rational?
That’s the point of a fascinating new article over on O’Reilly Radar, on lab “mythology”. As the author says, “Each lab has its own ritualized behavior that ‘works.’ Whether it’s protocols, lucky machines, or common knowledge that’s picked up by every student in the lab (but which might not be the same from lab to lab), the process of doing science is an odd mixture of rigor and folklore. Everybody knows that you use 42 C for 45 seconds, but nobody really knows why. It’s just what you do.”
The article calls for a “big data” approach to take benchwork out of the realm of ritual. Each component, including details as small as which pipets are used, should be defined. Eventually, the author argues, the experiment should be run like a computer program, with the exact steps described in a specialized programming language. But is this likely to happen in the “real world” of biology research? Can and should biological practice truly be quantified this way?
As regular readers know, I’m a research biologist who now works in bioinstrumentation. I write a lot of programs for computer-controlled lab equipment, and I have been spending the last few months teaching a robot how to do a Western blot. That means, I have had to think programatically about an operation that I usually do pretty much by instinct. I’ve performed several hundred Westerns in my career, so I tend to just flow through the procedure with an occasional glance at the protocol, and I fix any issues that arise without much thought.
However, computers don’t do instinct. They do what you tell them to. So, I’ve had to think rigorously about each step in the protocol: how thoroughly you empty the tray between blot washes, precisely how much agitation to use, exact volumes of buffer, and so on.
As the O’Reilly article puts it, “… programming forces you to describe the process precisely and completely, in a standardized language that is meaningful in different contexts, different labs.” It has turned out to be a very interesting process, and you may want to try it yourself – as laboratory automation and “big data” become more common, I believe that most working biologists will have to become comfortable with this way of communicating science.
“Lucky” scientific devices are interesting from a mechanical perspective, too. One of my major projects at my company is to develop biological QA for our devices, and to use those tests to better understand what properties of the machine contribute to success and reliability on the bench. If we have two machines that appear to be identical in every measurement we take, but which give different results when used on the same sample, then clearly we aren’t measuring all the right things!
As the article says, these critical factors could be subtle and unexpected, such as small scratches in a plastic surface that can harbor microbes. I’ve also heard about issues that turned out to be due to what equipment a device was sitting next to – an incubator’s compressor blowing hot air into another machine’s intake can have very unpleasant results! So, a “lucky” machine could just be one whose un-measured operational quirks happen to match up well with the particular way a lab tends to do an experiment. Which kind of sucks when another lab is trying to reproduce their results.
One weakness of the article, though, is that it doesn’t fully comprehend or account for the inherent variability of living things, or how hard it is to measure that variability. The problem is like the problem of teaching a computer to cook, only more so: not only are the inputs variable, but they will be constantly changing because they are usually still alive.
One of my company’s big sellers is a sample homogenizer, and I often do protocol development for it. Even with the very same machine, the best protocol will depend on the exact properties of the sample, which can be influenced by something as simple as the weather two weeks before harvest. A human scientist who is familiar with the sample may subconsciously adjust technique to compensate for this difference, but most devices won’t. In the same vein, subtle differences in anatomy or cell growth conditions will require deep knowledge to automate.
So, since this is a careers Website, what does this probably mean for your career as a biologist?
First, I think it is almost certain that automation will replace most rote benchwork within 15 years or so. When I was a grad student, most labs used “homebrew” methods for things like plasmid purification, but everyone uses kits now – they are a bit more expensive, but much faster and more consistent. Small robots will take over for simple lab tasks the same way.
This will open up job opportunities for people who are interested in biology and machines (like yours truly), but any biologist should at least be aware of emerging technologies and what that means for her own work. You should use and exploit automation in areas where you can, and concentrate cleverness in areas that are harder to automate and where “artisanal” thinking is still valuable. Do not let yourself get trapped in a position of being a slower and less precise robot.
I believe it will also be helpful to at least understand the logic of programming. Not necessarily because you need to write code, but because I think more scientific practice will be described in a more code-like way in future. It is also a useful tool for thinking rigorously about your work, which is a good thing even if you’re not anywhere near a computer.
Got an opinion about lab automation? What do you think we will gain and lose during this transition? Speak out in the comments, or drop me a line at firstname.lastname@example.org.