Technical Debt and Code Migration

RSEs often have to deal with code which wasn’t originally designed with testing, maintenance orperformance in mind, or was written in a language or a style which is now considered outdated,obsolete or insecure. This is a problem for RSEs writing and maintaining software for long-livedresearch programs, who may be slowed by this technical debt. A common response is to start aproject to rewrite the code in another programming language or an updated framework, and inparallel to make functional improvements. Anecdotally, this kind of project is at risk of delaysand cost-overruns.In some fields, like web programming, the time for a framework to appear, reach its zenith ofpopularity, and then become uninteresting and obsolete, might be a handful of years. In others,code which has been in use for decades continues to be used.In this talk I’ll discuss some of the lessons our group learned during upgrade projects, and askwhat we might be able to learn from long-lived code.First we’ll look at a project to migrate an image processing pipeline from MATLAB to Julia andmake it HPC-ready. We’ll focus on the availability of ready-to-use image processing functions,the costs of reimplementation, and the characteristics which help a library to endure.Then we’ll look at how our group has standardized its web development stack, and what welearned about React, Tailwind, Typescript, Vite and Next.js. We’ll also look at how changes inGoogle Firebase hosting, which were meant to make developers’ lives easier, made our codereview process much less intuitive, and how that was resolved.