osharav

"For my birthday I got a humidifier and a de-humidifier... I put them in the same room and let them fight it out." --Steven Wright

Interesting to compare this with a simpler term - "Red herring" as something that throws you off course.

From what you say there is no real outsider's view. To do the homework I would have to be on the inside. Fair enough, if that is the entry level, I guess I really can't offer any new ideas.

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).

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.

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.

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.

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

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

New link: https://medium.com/@osharav/develop-drugs-like-we-do-softwar...

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.

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.