The title of this article might suggest a discussion about art or traditional software engineering. However, my focus is on neither and both, it is on what I see as the intersection. I want to reflect on my experiences in refactoring and reusing codebases developed by researchers. It was a journey with lots of ups and downs, but in the end, I have learned something that I want to share.
Starting with art, the first thing that comes to my mind is the difficulty of defining what art is and that says a lot about art. But to me, art is the expression of an individual that is not confined by reality, norms, or functionality. It evokes emotions and is open to interpretation. Most importantly, art leaves room for imagination. The greatest pieces of art I have seen aren’t necessarily the most technically complex ones but the ones that leave you with more questions than answers and room to imagine. They even surpass the limitations of the medium in which they are produced. Keep these qualities of art in mind and let’s see what software is.
For most large companies, software engineering is explicitly not that: it’s about writing in a common language with your fellow programmers as well as sharing “cultural norms” like coding conventions, reviews, and tests. A great lesson a software engineer should learn is that source code should not be written for the computer to execute, but it should be written for peers to understand and maintain. Code reviews are there to ensure this. There are good reasons for all of these things! But the end product should rarely resemble any qualities of “art”.
Research code is different. It lies somewhere between strict engineering and free-form art. It’s about exploring unknown areas and trying out ideas without a clear path. This process is dynamic and evolves as the researcher makes new discoveries. This makes the research code a personal reflection of a researcher’s thoughts and creativity.
This type of code varies a lot between researchers, even when they are looking at similar problems. It’s shaped by each researcher’s personal approach and their interactions with the problem. Often, it doesn’t follow the ‘best practices’ of software engineering, either because the researchers are unaware of these practices or because they choose to prioritize other aspects of their work. Like art, research code often raises more questions than it answers and reflects a personal and intellectual journey.
After working with research code for a while, I’ve learned to appreciate its unique qualities. Instead of seeing its lack of structure as a problem, I view it as a rich record of a researcher’s exploration and challenges. It shows the process of discovery and the personal experiences of the researcher. Going through some research codes, I feel the pain, joy, frustration, and excitement of discovery that the original author went through. It was harder to feel the joy at first but the more I understood the context, the more I could appreciate their endeavor, and see the beauty there.