One of the things that no one realizes about research (until they’ve done some) is how much time can be spent going back over things. Right now I’m fighting some experiments that should be working, have worked in the past, but have (for some reason) decided not to work at the moment. Irritating stuff. There’s a reason buried in there somewhere, and when I find it things will be that much more robust in the future, but I’d hoped that they were that solid already.
And across the hall, a check is going on of some screening hits. When you get a pile of fresh high-throughput screening data, including some fine-looking starting compounds for a new project, what do you do with it? Well, if you have some experience, the first thing you do is order up fresh samples of all the things you could possibly be interested in, and check every single one of them to make sure that they actually are what they say on the label. Don’t start any major efforts until this is finished.
In fact, you should order up solid samples from the archives along with some of the DMSO stock solution that they used in the screening assay. They might not be the same, not any more. False negatives and false positives are waiting in your data set, depend on it: compounds that should have hit, but didn’t because they decomposed in solution, and compounds that (sad to say) did hit only because they decomposed in solution. You’ll probably never know about the first group, and you can waste large amounts of time on the second unless you check them now.
Getting a project going, then, can seem like trying to get a dozen nine-year-olds into a van for a long trip. Someone’s always popping out again, having forgotten something, which reminds someone else, and your scheduled departure time arrives with everyone running in circles around the driveway.
But nine-year olds can eventually be corralled, as can the variables in most scientific projects. But not always. Where you don’t want to be is the situation people had with the early vacuum-tube computers. Vacuum tubes have not-insignificant failure rates. So if you have, say, twenty thousand of the little gizmos in your ENIAC or whatever, doing the math on mean-time-between-failures shows you that the thing can run for maybe forty-five minutes before blowing a tube (unless you take heroic measures). And the more vacuum tubes you have, the worse the problem gets: make your computer big enough, and it’ll blow right after you throw the switch, every time.
So that’s the other thing you have to watch when troubleshooting: try to make sure that your problems aren’t built into the very structure of what you’re trying to do. In med-chem projects, look out for statements like “we have all the activity we need, now we just need to get past the blood-brain barrier”. Sometimes there’s a way out of those tight spots, but too often the properties that (for example) could get your compound into the brain are just flat incompatible with the ones that gave you that activity in your assay. You’d have been better off approaching that combination the other way around, and better off realizing that months ago. . .