Medical research should not be in a crisis. More people than ever before want its products, and have the money to pay for them. More people than ever want to work in the field as well, and they’re uncannily brilliant and creative. It should be a golden era. So the myriad of problems faced by this industry–sources of revenue slipping away from pharma companies, a shift of investment away from cutting-edge biomedical firms, prices of new drugs going through the roof–must lie with the development processes used in the industry.
Like many other industries, biomedicine is contrasted with the highly successful computer industry. Although the financial prospects of this field have sagged recently (with hints of an upcoming dot-com bust similar to the early 2000s), there’s no doubt that computer people have mastered a process for churning out new, appealing products and services. Many observers dismiss the comparison between biomedicine and software, pointing out that the former has to deal much more with the prevalence of regulations, the dominance of old-fashioned institutions, and the critical role of intellectual property (patents).
Still, I find a lot of intriguing parallels between how software is developed and how biomedical research becomes products. Coding up a software idea is so simple now that it’s done by lots of amateurs, and Web services can try out and throw away new features on a daily basis. What’s expensive is getting the software ready for production, a task that requires strict processes designed and carried out by experienced professionals. Similarly, in biology, promising new compounds pop up all the time–the hard part is creating a delivery mechanism that is safe and reliable.
Generating Ideas: An Ever-Improving Environment
Software development has benefited in the past decade from an incredible degree of evolving support:
-
Programming languages that encapsulate complex processes in concise statements, embody best practices, and facilitate maintenance through modularization and support for testing
-
Easier development environments, especially in the cloud, which offer sophisticated test tools (such as ways to generate “mock” data for testing and rerun tests automatically upon each change to the code), easy deployment, and performance monitoring
-
An endless succession of open source libraries to meet current needs, so that any problem faced by programmers in different settings is solved by the first wave of talented programmers that encounter it
-
Tools for sharing and commenting on code, allowing massively distributed teams to collaborate
Programmers have a big advantage over most fields, in that they are experts in the very skills that produce the tools they use. They have exploited this advantage of the years to make software development cheaper, faster, and more fun. Treated by most of the industry as a treasure of intellectual property, software is actually becoming a commodity.
Good software still takes skill and experience, no doubt about that. Some research has discovered that a top programmer is one hundred times as productive as a mediocre one. And in this way, the programming field also resembles biology. In both cases, it takes a lot of effort and native talent to cross the boundary from amateur to professional–and yet more than enough people have done so to provoke unprecedented innovation. The only thing holding back medical research is lack of funding–and that in turn is linked to costs. If we lowered the costs of drug development and other treatments, we’d free up billions of dollars to employ the thousands of biologists, chemists, and others striving to enter the field.
Furthermore, there are encouraging signs that biologists in research labs and pharma companies are using open source techniques as software programmers do to cut down waste and help each other find solutions faster, as described in another recent article and my series on Sage Bionetworks. If we can expand the range of what companies call “pre-competitive research” and sign up more of the companies to join the commons, innovation in biotech will increase.
On the whole, most programming teams practice agile development, which is creative, circles around a lot, and requires a lot of collaboration. Some forms of development still call for a more bureaucratic process of developing requirements, approving project plans, and so forth–you can’t take an airplane back to the hanger for a software upgrade if a bug causes it to crash into a mountain. And all those processes exist in agile development too, but subject to a more chaotic process. The descriptions I’ve read of drug development hark of similar serendipity and unanticipated twists.
The Chasm Between Innovation and Application
The reason salaries for well-educated software developers are skyrocketing is that going from idea to implementation is an entirely different job from idea generation.
Software that works in a test environment often wilts when exposed to real-life operating conditions. It has to deal with large numbers of requests, with ill-formed or unanticipated requests from legions of new users, with physical and operational interruptions that may result from a network glitch halfway around the world, with malicious banging from attackers, and with cost considerations associated with scaling up.
In recent years, the same developers who created great languages and development tools have put a good deal of ingenuity into tools to solve these problems as well. Foremost, as I mentioned before, are cloud offerings–Infrastructure as a Service or Platform as a Service–that take hardware headaches out of consideration. At the cost of increased complexity, cloud solutions let people experiment more freely.
In addition, a bewildering plethora of tools address every task an operations person must face: creating new instances of programs, scheduling them, apportioning resources among instances, handling failures, monitoring them for uptime and performance, and so on. You can’t count the tools built just to help operations people collect statistics and create visualizations so they can respond quickly to problems.
In medicine, what happens to a promising compound? It suddenly runs into a maze of complicated and costly requirements:
-
It must be tested on people, animals, or (best of all) mock environments to demonstrate safety.
-
Researchers must determine what dose, delivered in what medium, can withstand shipping and storage, get into the patient, and reach its target.
-
Further testing must reassure regulators and the public that the drug does its work safely and effectively, a process that involves enormous documentation.
As when deploying software, developing and testing a treatment involves much more risk and many more people than the original idea took. But software developers are making progress on their deployment problem. Perhaps better tools and more agile practices can cut down the tool taken by the various phases of pharma development. Experiments being run now include:
-
Sharing data about patients more widely (with their consent) and using big data to vastly increase the pool of potential test subjects. This is crucial because a a large number of tests fail for lack of subjects
-
Using big data also to track patients better and more quickly find side effects and other show-stoppers, as well as potential off-label uses.
-
Tapping into patient communities to determine better what products they need, run tests more efficiently, and keep fewer from dropping out.
There’s hope for pharma and biomedicine. The old methods are reaching the limits of their effectiveness, as we demand ever more proof of safety and effectiveness. The medical field can’t replicate what software developers have done for themselves, but it can learn a lot from them nevertheless.
