
Develop drugs like we do software - osharav
https://medium.com/@osharav/develop-drugs-like-we-do-software-finding-the-right-unit-tests-80e6885a5dae
======
xkcd-sucks
This 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. 

~~~
osharav
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. 

------
dalke
> "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? 

~~~
osharav
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. 

~~~
dalke
As with just about everything to do with chemistry and drug development, the
answer is "maybe". 

It depends on the model, it depends on the failure, it depends on so many
different factors. 

For example, it may be that in human trials the new drug X is better than
nothing, but not as effective as an older, generic drug A, which costs $0.10
per pill. 

That's a market failure, but it's not possible to feed that back into the
model. 

Or, look at the TGN1412, where all 6 volunteers for first-in-man Phase 1 tests
has to be hospitalized; 4 with multiple organ disfunctions and may never fully
recover. 

That doesn't require a simple fix to the existing model, but a investigation
into how the underlying mechanism works. 

But in general, yes, absolutely the information is fed back into the
development process. 

That said, I can make no sense of your analogy to unit testing.  Drug molecules
aren't meaningfully decomposed into individual units that can be tested, and a
modification in one structure which may be deleterious may be beneficial if
done to another structure.  There are rules of thumb ("Rule of 5", "magic
methyl"), and more statistics-based model ("Free-Wilson model", "matched
molecular pairs"), but they do not ensure that there will/won't be a problem,
only enrich the likelihood of finding what you are looking for.  Hopefully. 

Based on what you've written, including your lack of knowledge of QSAR, no, I
don't think you know much about drug development. 

You have a new account, so I will explain what my comment means.  At HN, the
readers are also semi-moderators.  By making my comment, I _was_ doing the
first step towards "contact[ing] the administrator", and letting the submitter
(that is, you), know that it is a poor fit for HN. 

The HN guidelines say that topics should be on "Anything that good hackers
would find interesting."  I am a good hacker.  I also write software for drug
development.  I did not find the piece to be interesting.  I found it to be
dismissive of the hundreds of thousands of people who have worked in drug
development, and long ago put iterative processes and quality control methods
in place. 

I guess if you don't like my comments, you too can file a complaint with the
administrator.  I will continue to criticize articles that I think have little
understanding of topics that I know something about. 

~~~
osharav
Fair enough, although I think that discussing and further thinking about that
analogy might be able to create new insights.  I find it unfortunate that in
addition to highly interesting information you've shared, you have also chosen
to make destructive criticism about my attempt to find touch points between
software and drug development.  See, software development, the way I see it, is
based on sharing, via open source, but not only.  The culture it induces is of
being open, to new ideas and to constructive criticism. 

> Drug molecules aren't meaningfully decomposed into individual units

It's not about the molecules - it's about the tests.  Envision a state where
you could say - "oh dear, 6 volunteers for first-in-man Phase 1 tests had to
be hospitalized - let's find a lab test, or a change in the model which would
predict a positive result for the structure we've tested and negative result
for other structures which do not cause that condition".  The individual units
don't have to be the molecules, they can also be the tests.  You would argue,
and rightly so, that finding such a test is hard/impossible.  And I would agree
but the whole article is about defining the problem - and because in software
development, when making a small bug fix - you are not after making the entire
system work, rather a tiny fraction of it better apt for a new condition you
did not take care of earlier. 

> the answer is "maybe"

When uncertainty is high - wouldn't you want to strengthen the tools that
allow you to know at least that the failures you've already encountered won't
happen again? 

I find it also unfortunate that you think my article is dismissive of efforts
made by countless people before me.  I had and have no such intention. 

~~~
dalke
If you think my comments are "destructive criticism" then I invite you to post
to a medchemist's site, like Derek Lowe's, or present at a medchemist's
conference and see the responses you get. 

By giving you all these pointers I am trying to provide the "constructive
criticism" you say you want. 

I am also trying to establish my bona fides, so you might have a chance of
accepting as true my statement that you've offered no insights which were not
already known a century ago.  It's not like the concepts underlying unit
testing didn't exist before CS developed them. 

And I have no wish to put up with an eternal September here on HN when some
enthusiastic engineer thinks the methods from that field can be moved over to
drug development.  It very similar to what Lowe, above, calls the 'Andy Grove
fallacy' \-
[http://blogs.sciencemag.org/pipeline/archives/2015/04/02/sil...](http://blogs.sciencemag.org/pipeline/archives/2015/04/02/silicon_valley_sunglasses)
. 

Also, there's an entire field for the theory of the design of experiments:
[https://en.wikipedia.org/wiki/Design_of_experiments](https://en.wikipedia.org/wiki/Design_of_experiments)
.  These are used in drug development.  Perhaps it's _software development_
which should incorporate ideas drug development, and not the other way around. 

~~~
osharav
I am not saying that Computer Engineering (not science) can magically overcome
the challenges of drug development - that would indeed be fallacy.  I am saying
that one of the challenges in software development is to maintain progress in
an ever changing world of modifications done to the product.  I see similar
challenges in the drug development field - And so I try to find the link
between what has worked in software development to what exists in the drug
development area.  You say that due to the complexity of drug development and
the huge difference between the two fields all I can say is that in both
worlds we conduct experiments and in the drug development area you have a far
better understanding of how to conduct these experiments effectively. 

You know better than me.  You're right, I can offer no new insights, only the
knowledge gained from experience (not necessarily theory).  And from my
experience what makes a product work is not the algorithms used, or the number
of people working on it, or the technology used - it is how its progress is
maintained via automated/constant testing. 

If you think that the resources spent on maintaining progress in the drug
development world are suitable - that's good to know. 

~~~
dalke
Quoting from that Derek Lowe link to
[http://blogs.sciencemag.org/pipeline/archives/2015/04/02/sil...](http://blogs.sciencemag.org/pipeline/archives/2015/04/02/silicon_valley_sunglasses)
since it seems to describe your situation almost perfectly:

> There’s another problem that’s not unique to [Silicon] Valley, although it
> does tend to give people a bad case of it.  That’s the “Clearly I’m smart and
> successful, so clearly I have something to offer in this other field over
> here” one.  We all succumb to that one now and then; it’s human nature. ... 
> If you’re used to being able to sit down and bang out code, any time,
> anywhere, with all kinds of tools (libraries, compilers, virtual machines,
> what have you) at your fingertips, then yeah, working up a new assay
> protocol in a cell line is going to seem agonizingly slow.  Multibillion
> dollar ideas can be cranked out in the coding world very quickly, if you hit
> the right place at the right time, but just you try that in the lab. ...  The
> real bottlenecks are figuring out what assay to run, and what to do with the
> data once you have it. ... 

> As much as I might like to see something like that happening in biopharma,
> though, I can’t quite make myself believe it.  Technology, Silicon Valley
> style technology, is human-designed and human-optimized for other humans.  As
> human beings, we’re playing on our home turf there.  But the biology of
> disease is an away game if there ever was one.  The inner workings of cells
> and the ways that they work together are flat-out alien compared to anything
> we’ve ever built ourselves.  People who are used to coding up apps have never
> experienced anything like it, and many of them don’t seem to realize that
> they haven’t.  Expecting the sorts of behavior that you get from human-built
> technologies, and expecting the same effects from the techniques that work
> to optimize them, is an expensive accident waiting to happen. 

As a related example, in the early 1990s AutoCAD thought they could enter
molecular modelling, since they figured they could leverage what they knew
from designing structures to design molecules. 
[https://www.fourmilab.ch/autofile/www/chapter2_82.html](https://www.fourmilab.ch/autofile/www/chapter2_82.html)
.  You'll notice the lack of success, and HyperChem is a dead product. 

~~~
osharav
I can't really see how the quote from Lowe's article is a reply to what I've
written.  I've done my best to be as humble as I can while still trying to
offer something from my experience.  You seem to be fixed on an image.  You may
call it silicon valley way of thinking or Andy Grove fallacy.  It is
unfortunate that it prevented you from replying to what I've written and
instead caused you to paste in what is probably your auto response for any
kind of an outside look on your field. 

I sure hope you know what you're doing. 

~~~
dalke
The uniformly negative comments by others here suggests that it is not
uniquely I who misunderstand you. 

~~~
osharav
The uniformity of comments here worries me, as does Lowe's article. 

I think you are building a very tall wall. 

The gist of my article is: From my experience in my area, developing in a
complex environment requires the most investment not in the speed of
processing, not in the algorithms used, not in the amount of memory - but
mainly in ensuring constant progress.  I was deeply curious to learn what is
the equivalent in the drug development field. 

Yes the theory existed long before Computer Science and Engineering ever did -
but the experience did not. 

> “Clearly I’m smart and successful, so clearly I have something to offer in
> this other field over here”

Interestingly enough, I did not speak of my successes, or my reputation, or
other people who could say how great I am or even my current role.  No, you did
that. 

> You'll notice the lack of success, and HyperChem is a dead product. 

How ironic that you've stated one fallacy (success in one field -> success in
another) and then immediately used a similar one. 

> letting the submitter (that is, you), know that it is a poor fit for HN.  >
> Why is this linked-to from HN? 

I don't need to post anywhere to know that this is destructive criticism. 

Perhaps the ideas in my article are completely wrong - I can live with that. 
What worries me more is the culture which exists in your field, the notion
that you can dismiss so easily an outsider's look into your field instead of
trying to see exactly how it relates to it, why you think that the idea is
already implemented or should not be implemented and instead - spend so much
energy on trying to convince me that I should never even think about proposing
anything to any other field except my own. 

Us and them - I think this saddens me most - I'm them, you're us (and vice
versa from my POV). 

~~~
dalke
Again, you malign the entire field with such unsubstantiated claims that "the
experience did not".  You do not know the field.  You do not know what people do
in the field.  You simply don't have the knowledge to make that assertion. 

This is identical to the casual arrogance of the smart but uninformed, which
is why I keep reading that interpretation into your comments.  You have said
nothing which convinces me that you are informed, even to a undergraduate
level, of the field. 

Drug discovery is a highly multidisciplinary field with "outsiders" constantly
entering the field.  There is no wall.  There _are_ large pits.  Some look
enticing.  It's taken a lot of time, toil, tears, and cash to map out the pits. 
Many of them are well-known, via papers and books, or word-of-mouth.  New ones
keep appearing as we map thing out. 

This is like a newcomer from out of state who arrives, and before even looking
at a map exclaims "you yokels should go that way, because this looks like
region X back home, and we've figured out how to get through X in the 1970s." 
Only, the locals respond "yes, new people often think that, but we figured out
back in the 1920s how to get through the area, have since built a four-lane
highway through it, and if you go that way you're going to fall into
quicksand." 

The idea that an outsider with different experience can provide fresh insight
is enticing.  But software developers with agile experience who work in drug
discovery is not an outsider view. 

My reaction isn't "us vs. them", it's annoyance over people who don't do their
homework. 

------
tired_man
What?  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. 

~~~
osharav
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

------
jacquesm
Move fast and kill people. 

~~~
osharav
Which is exactly what you cannot do, the moral and legal constraints dictate
that we probably need some other mechanism. 

------
osharav
New link: [https://medium.com/@osharav/develop-drugs-like-we-do-
softwar...](https://medium.com/@osharav/develop-drugs-like-we-do-software-
finding-the-right-unit-tests-80e6885a5dae#.7hekxqlgq)

