Writing computer code resembles a fine art because it carries a particular aesthetic that is often independent of its purpose. Sometimes style matters, and as a result, many programmers maintain that their dinstictive styles are important to the outcome of their work.
The intensely self-referential nature of computer programming, combined with the complexity of the biological systems we want to simulate, means that most computational biophysicists are more like disk jockeys than virtuosos. In my mind, it’s far better to combine samples of robust, well-validated code to run a simulation than to reinvent years of research and development to study a biological problem in silico. I think this is also a natural feature of both basic science research, which should be exploratory, and biological simulation, which must be carefully tailored to real experiments, otherwise they might be meaningless.
These features all lend themselves to a specific coding style which relies on many different tools at once. For example, my most recent paper describes a method for understanding how proteins communicate over long distances to self-assemble and bend membranes. Besides using the GROMACS molecular dynamics integrator, the calculations presented in that paper call several important libraries, from SQL (via SQL alchemy) to a popular fast Fourier transform library wrapped by numpy. These calculations would surely be intractable without thousands of man-hours of labor which made it easy to adapt other codes for use in my own.
The relatively mature state of scientific computing has many upsides a couple of downsides. There are many advantages to using robust, validated, and highly optimized codes. My computations can be fast and reliable, I can make contact with a huge body of literature to make sense of them, and best of all, I can spend more time standing on the shoulders of giants instead of reinventing the wheel.
There are two significant downsides. Sometimes you cannot be sure that you’re using the best code. While fftw is a robust industry standard, other sprawling libraries like scipy have a mixture of different functions, calls to many other libraries, and a very wide developer base. This this makes them somewhat less predictable. It takes a careful practitioner to be sure that every dependency works as advertised. This problem is best known as the black box problem: we outsource a part of our computation to a machine, without knowing or checking precisely how it works. This carries an inherent risk that we have either misunderstood the black box, or worse, that it makes a mistake.
There is another, more existential downside. Even if all our black boxes are perfect, the set of tools we use is inherently limited by earlier design descisions. This means that the cost of making new tools might sometimes be high enough to restrict our attention to tantalizing tools that are already on the shelf. The high cost of making useful tools means that we are always choosing from a restricted set of options, and that our methods may become a type of cargo cult in which a flashy calculation has only a glancing relation to a scientifically meaningful insight.
This caveat is part and parcel of any kind of scientific inquiry which seeks novelty and reliability at the same time. It’s important to be mindful of the balance between writing something yourself and relying on standardized tools for the job. The best coders and simulation experts should strive to compromise between checking their work and writing new codes, using off-the-shelf codes only if they can be sure the are reliable. We want to avoid generating new theories that are so novel that they are wrong.