Develop drugs like we do software
medium.com
Develop drugs like we do software
1–10 of 21 posts
Re: Develop drugs like we do software
#2What? Do you mean using AGILE techniques?
I think I'd rather they take the time to actually come up with the right answer first. I don't think submitting a JIRA is very effective after you're dead from something they thought they could push to the next sprint.
Re: Develop drugs like we do software
#3This is the sort of thing that gets written when well-meaning software engineers write about stuff they know little about.
Testing early drug candidates on living critters is already a thing, and has been a thing since forever. It's referred to in the industry as "phenotypic screening." In vitro testing emerged because it's expensive and possibly unethical to use huge numbers of mice/digs/people to test drugs in the pipeline. There's been a resurgence of phenotypic testing as the miracles promised of various screening technologies promised in the 1990s-2000s have failed to deliver.
Iterative refinement of drug structures has also been a thing since pretty much forever. Similar structures behave similarly. Changing stuff is somewhat predictable, and modifications are introduced at all stages of the pipeline. For example, a structure might first be tweaked for receptor binding, then for solubility, then for ease of.manufacture, etc.
Re: Develop drugs like we do software
#4Move fast and kill people.
Re: Develop drugs like we do software
#5> "In drug development however, it takes a very long time to know that a candidate for a drug doesn’t work."
Mmmm, only somewhat. At the beginning there are million or billions of candidates. Most of them are easily rejected. It's only a few of the candidates which get far enough along to go into animal or even human testing which cost the big bucks.
> "Tests in a lab can be automated, are a lot cheaper and take much less time to execute."
As in, combinatorial chemistry? Big arrays of screening robots? DNA-encoded chemical libraries?
> "I claim that we should turn our efforts to: 1) Make the in Vitro testing phase a more profound step in the process and as a result:"
Yup, sounds like combinatorial chemistry.
> "2) Find more tests which together provide better predictability of: a. More potency, b. Less toxicity"
Says pretty much everyone, for decades. It's hard to go to a QSAR conference and not hear about someone trying to do this.
> "3) Enable each iteration to make a small change to the candidate and repeat the process."
Yes, this is called QSAR.
> "Nowadays, if a drug fails the clinical trials phase a biochemical engineer may try to slightly alter it — and repeat the entire drug development process from scratch."
Ummm, what? No. It more often goes back to an earlier stage. It doesn't restart "from scratch." If you've got a good lead compound, you're going to "make a small change to the candidate", not go back to, say, virtual screening of millions of compounds from chemical space.
I don't think this author knows much about how drug development is done. Why is this linked-to from HN?
Re: Develop drugs like we do software
#6This is the sort of thing that gets written when well-meaning software engineers write about stuff they know little about. Testing early drug candidates on living critters is already a thing, and has been a thing since forever. It's referred to in the industry as "phenotypic screening." In vitro testing emerged because it's expensive and possibly unethical to use huge numbers of mice/digs/people to test drugs in the…
The article is not about testing on living creatures or about iterative refinement - it is about having the right unit tests to make sure that the iterative refinement predicts better the effect on living creatures.
I am indeed a well meaning software engineer who write stuff I know little about. That is because I don't think I can quit my day job and study biochemistry for a decade. What I can do is point out similarities between stuff I do know about and the field of drug development. If you don't find this useful or it doesn't trigger any new ideas (maybe totally different than the ones raised in my article) - then read on to the next one.
Re: Develop drugs like we do software
#7> "In drug development however, it takes a very long time to know that a candidate for a drug doesn’t work." Mmmm, only somewhat. At the beginning there are million or billions of candidates. Most of them are easily rejected. It's only a few of the candidates which get far enough along to go into animal or even human testing which cost the big bucks. > "Tests in a lab can be automated, are a lot cheaper and take much…
QSAR sounds very interesting, if I encounter a failure in later stages of drug development - can I feed that information back to the model? See I'm trying to understand if the concept of a unit test is present in the drug development field. Unit tests watch your back - whenever a bug is found you are required to both fix the bug and write a unit test which ensures the bug won't happen again. If QSAR has that - my article may well be redundant.
The author, me, knows a bit about drug development. But I do know about software development. If you find this not useful, read on to the next article.
> "Why is this linked-to from HN?"
This is linked from HN because I've published it there. I guess you can contact the administrator to notify him/her that someone is wrong on the internet.
Re: Develop drugs like we do software
#8Re: Develop drugs like we do software
#9What? Do you mean using AGILE techniques? I think I'd rather they take the time to actually come up with the right answer first. I don't think submitting a JIRA is very effective after you're dead from something they thought they could push to the next sprint.
I mean finding the equivalent of unit tests in drug development. If it's already there - great. If not - let's file a Jira to research that backlog item
Re: Develop drugs like we do software
#10Move fast and kill people.
Which is exactly what you cannot do, the moral and legal constraints dictate that we probably need some other mechanism.