Drug discovery is like the worst imaginable, old-style software development process, guaranteed to take forever, cost endless amounts of money, and far under-achieve its potential. There are methods that the most advanced software people use to build effective software that works in the real world, quickly and inexpensively. These small groups invent all the new things in software, and then get bought by the big companies.
Can these fast, agile, effective methods be applied to invent and test new, life-saving drugs and get them to the patients who are dying without them? Yes. The obstacles are the usual ones: the giant regulatory bureaucracies and the incumbents who would be disrupted. Yes, the very people who claim to keep you healthy and cure your ills are the very ones standing between us and speedy drug discovery.
Drug Discovery and Software
While I'm not an expert in drug discovery, I've learned more than I wish to know about the regulations through the software providers to the industry. And like many other people, I've learned from being a patient with a disease that could be addressed by drugs that I am not allowed to take, because they are deep in the labyrinth of the years-long approval process.
I've explained elsewhere how a revolution in medical device innovation could be enabled by transforming the applicable regulations from complex, old-style software prescriptions to simple, goal-oriented ones.
A similar concept can be applied to the process of drug discovery itself.
Old-style Software is Like the FDA's New Drug Regulations
The classic software development process is a long, expensive agony. It's an agony that sometimes ends in failure, and sometimes ends in disaster. It most resembles carefully constructing Frankenstein's monster. It starts with requirements and goes on to various levels of design, planning and estimation. Finally the build takes place. But wait -- we can't "release" the software until we know that its quality is top-notch. And that it meets all the requirements. It's gotta work! So let's make absolutely sure that it's up to snuff before inflicting it on the innocent users. Here are details.
Yes, those innocent users -- who are, by the way, chomping at the bit to get at the long-awaited new software whose requirements they signed off on years ago, and that they actually need to get their jobs done.
So is software development like drug discovery? Let's see.
- Development that's a long, expensive agony. Check.
- Don't release it until its adequacy is PROVEN. Check.
- People who are just dying to use it. Check.
But here's the difference: for software, usually one company both builds it and decides whether and when to release it. That means the business leaders of the company can balance the tension between adequacy and getting it out there. In the case of drugs, it is adversarial: the FDA declares how each step of drug discovery and testing has to be done, and has armies of people to impose its will on the companies that do the work.
The FDA Nightmare
The FDA nightmare has two main parts.
The first nightmare assures that development and testing is performed in what is claimed to be the "safest" way possible -- it's all about protecting patient health! In fact, this means incredibly slow and incredibly expensive. The overhead is far more burdensome than the work itself, which really tells you something. There is a multi-billion company, Documentum, that got started with and still is the leading provider of software to the pharmaceutical industry for handling the documents required by the FDA. Right away, this expense and overhead burden assures that no group of brilliant people will create a start-up and create a new cure for a disease.
The second nightmare is that the process is incredibly high risk. The FDA can kill your new drug at any time, including near the end, after all the time and money is gone. This again reduces the number of groups performing new drug development to a tiny number of rich, giant, risk-averse corporations.
This is like big-corporate software development -- only far worse.
Wartime Methods for Drug Discovery
I've written a lot about wartime software development. A good way to understand it is to look at bridges in peace and war. In wartime, we build effective bridges while under fire in a tiny fraction of the time needed in peace. And the bridges work.
The methods translate well to software. They are practical. They work. They are in regular use by groups that are driven to innovate and get stuff done. There are details in my book on the subject, with lots of examples and supporting material in my other books.
It's very clear that the methods also apply to the FDA's regulation of software. Here is an example. There is no reason other than the usual obstacles to innovation that the principles couldn't be applied to drug discovery in general.
Wartime Drug Development
What we should try is Wartime Software Development morphed into Wartime Drug Development. Here are the principles:
- Grow the baby.
Instead of going through a whole long process and supposedly coming out with perfection at the end, you start with something that sort of works, try it (on volunteers), see how it goes, make changes and iterate.
- Principles of e-commerce and social media
When you think of buying a product, do you just walk into a store and trust the salesperson? If so, you're probably in your 100's and hope to get a computer someday. Everyone else goes on-line, checks reviews, and above all checks comments from real users. The sheer number of comments tells you how popular something is. Of course, you don't blindly believe everyone, and of course you translate what people say to your own situation. There could be awful risks and side effects, but if it sometimes works and your alternative is misery shortly followed by death, you might decide it's worth the risk.
It's a decision that should be in your hands, informed by full sharing and disclosure, not decided on your behalf by a bunch of bureaucrats sitting in offices.
- Open source and full disclosure.
Of the top million servers on the internet, over 95% run linux, an open source operating system. Linux was created by an interesting nerd, and developed by an evolving band of distributed volunteers. It is superior to any commercial operating system. And operating systems are complex; linux contains more than 12 million lines of code! Why shouldn't we make drug discovery open to a similar process? With open source, everything about a drug and its results so far would be open and available for anyone, including patients, to see. Patients and researchers would all be active participants in the open discussions.
- Continuous release
The most advanced sites first bring up their software in extremely limited, volunteer-only releases. Everything is tracked. If things go well, more people can be invited in. Incredible tracking, lots of feedback, explicit and implicit. As software goes into wider release, a new version of it may be made available to a combination of new and existing users. Its use may be expanded, or it may be withdrawn. The process is continuous and iterative. It's called continuous improvement. We use it in lots of domains, ever since its use was formalized by W Edwards Deming in car manufacturing. It's not exactly weird or marginal. We simply refuse to apply its proven principles to drug discovery.
Conclusion
The FDA says its mission is to keep us safe. The gigantic bureaucratic monolith in practice assures that new drug development is performed by a tiny number of elite corporations at great expense, and rarely. Let's at least try a better way of doing things!
Comments