Are MATLAB users increasingly "Reluctant Developers"?
I wanted to share something I've been thinking about to get your reactions. We all know that most MATLAB users are engineers and scientists, using MATLAB to do engineering and science. Of course, some users are professional software developers who build professional software with MATLAB - either MATLAB-based tools for engineers and scientists, or production software with MATLAB Coder, MATLAB Compiler, or MATLAB Web App Server.
I've spent years puzzling about the very large grey area in between - engineers and scientists who build useful-enough stuff in MATLAB that they want their code to work tomorrow, on somebody else's machine, or maybe for a large number of users. My colleagues and I have taken to calling them "Reluctant Developers". I say "them", but I am 1,000% a reluctant developer.
I first hit this problem while working on my Mech Eng Ph.D. in the late 90s. I built some elaborate MATLAB-based tools to run experiments and analysis in our lab. Several of us relied on them day in and day out. I don't think I was out in the real world for more than a month before my advisor pinged me because my software stopped working. And so began a career of building amazing, useful, and wildly unreliable tools for other MATLAB users.
About a decade ago I noticed that people kept trying to nudge me along - "you should really write tests", "why aren't you using source control". I ignored them. These are things software developers do, and I'm an engineer.
I think it finally clicked for me when I listened to a talk at a MATLAB Expo around 2017. An aerospace engineer gave a talk on how his team had adopted git-based workflows for developing flight control algorithms. An attendee asked "how do you have time to do engineering with all this extra time spent using software development tools like git"? The response was something to the effect of "oh, we actually have more time to do engineering. We've eliminated all of the waste from our unamanaged processes, like multiple people making similar updates or losing track of the best version of an algorithm." I still didn't adopt better practices, but at least I started to get a sense of why I might.
Fast-forward to today. I know lots of users who've picked up software dev tools like they are no big deal, but I know lots more who are still holding onto their ad-hoc workflows as long as they can. I'm on a bit of a campaign to try to change this. I'd like to help MATLAB users recognize when they have problems that are best solved by borrowing tools from our software developer friends, and then give a gentle onramp to using these tools with MATLAB.
I recently published this guide as a start:
Waddya think? Does the idea of Reluctant Developer resonate with you? If you take some time to read the guide, I'd love comments here or give suggestions by creating Issues on the guide on GitHub (there I go, sneaking in some software dev stuff ...)
6 Comments
Time Descending
I think it is important to anchor this discussion in the scope statement of the MATLAB Coding Guidelines themselves:
“Primarily targeted at teams of MATLAB developers contributing to a large application or library.”
That qualifier matters.
I fully support good coding practices, and I think version control, testing, and consistency are enormously valuable when developing large, shared codebases. Or even small personal codebases. However, not all MATLAB code lives in that domain.
There is a meaningful distinction between:
- Developing a long-lived application with multiple contributors and external users, and
- Writing mathematical or engineering research code whose primary purpose is to explore, validate, and communicate ideas.
Research code often has:
- No external customer.
- No formal release cycle.
- Rapid, exploratory evolution.
- Forked or adapted versions tied to specific experiments.
- Variable names that must align with established mathematical notation.
For example, consider the quadratic formula which converts directly to MATLAB as something like:
x_p = (-b + sqrt(b^2 - 4*a*c)) / (2*a);
x_m = (-b - sqrt(b^2 - 4*a*c)) / (2*a);
No professor would benefit from renaming a, b, and c to some looooong descriptive names that programmers would have us all using:
x_positive_term = (-quadraticTermCoefficient + sqrt(linearTermCoefficient^2 - 4*quadraticTermCoefficient*constantTerm)) / (2*quadraticTermCoefficient);
x_negative_term = (-quadraticTermCoefficient - sqrt(linearTermCoefficient^2 - 4*quadraticTermCoefficient*constantTerm)) / (2*quadraticTermCoefficient);
This does not scan, cannot be shown sensibly on a slide to a class, does not match the literature. In research code, fidelity to the literature is often more important than descriptive verbosity. The code must map cleanly to equations in papers and textbooks, something that is less commonly a factor in the average programmers life. For researchers the code is a tool which is just a part of a much larger context and must connect with and make sense in relation to their entire research landscape.
Similarly, exploratory research workflows often prioritize iteration speed and conceptual clarity over formal release engineering. The optimization criteria are different: insight and reproducibility to the author and their immediate colleagues, not customer-facing robustness or long-term maintainability across large teams.
That does not mean research code should be sloppy. It means that coding practices should be domain-appropriate. The “right” level of tooling, structure, documentation, and process depends on:
- Team size,
- Expected lifespan,
- Reuse horizon,
- Audience and distribution,
- And the degree/speed to which the code is evolving versus stabilizing.
In my view, the conversation should not be framed as “MATLAB users becoming reluctant developers,” but rather as recognizing that MATLAB serves multiple domains, and each domain has legitimate, distinct equilibria. The key question is not whether everyone should adopt large-project workflows — but when those workflows provide net benefit relative to their cost, and how they can be tailored to suit researchers. Sadly that is the part of the conversation that usually is missing.
Thanks very much, @Stephen23. I agree with pretty much everything you wrote. In fact your final idea:
"The key question is not whether everyone should adopt large-project workflows — but when those workflows provide net benefit relative to their cost, and how they can be tailored to suit researchers."
is exactly the premise of this concept and the guide. I'm not suggesting that all MATLAB users should be adopting (reluctantly or not) software workflows. In the linked guide, I try to suggest which tools to adopt when and why based on the user's goal. I've bucketed into 3 goals, which I think give reasonable milestones that align with different answers to the considerations you list for finding the "right" level of tooling.
The first goal in the article is just getting code that can be rerun later and reproduce the same result, what I call "reproducible code" (inspired by the goal of reproducible research). My view is that if you don't need your results to be reproducible, you don't have a compelling need to adopt any software development tools and workflows. This is true of a lot of MATLAB code - once you get some insight or solve the problem at hand, you discard (or ignore) the code and move on. But if you do want your code to work tomorrow, or on somebody else's machine, you'll do yourself a favor by using git and maybe a Project (if your code is in multiple folders). I don't advise these users to follow the coding best practices, or adopt testing and CI - the idea is that the proposed tools line up with just the problems of writing reproducible code.
My thesis is that more MATLAB users are (or could be) recognizing the value of adopting some amount of software development tools to address real pains that they have today.
"My thesis is that more MATLAB users are (or could be) recognizing the value of adopting some amount of software development tools to address real pains that they have today."
My observation is that these tools were written by programmers for programmers. While the underlying tasks are fundamentally the same, the nomenclature, descriptions, and default options of many software development tools are specific to the programmers' domain, and may not represent how scientists, mathematicians, and engineers think about their work. Even the defaults and priorities of a tool like Git are not inherent in what the tool is doing, but are design decisions made by its authors to suit its authors. And the sneering of those same authors does not help bridge that gap.
Take the word 'commit': it carries no intuitive meaning for someone whose frame of reference is their wider landscape of a lab notebook, simulation run, manuscript revision, and bubbling vials on the counter top. The concept it represents (recording a known, reproducible state) is completely natural to any scientist. The label is not. This matters more than it might seem, because terminology shapes not just communication but cognition. When the vocabulary of a tool is alien, the mental model it encodes stays alien too, and adoption stalls not from unwillingness but from genuine conceptual friction.
The programmer community has sometimes responded to this friction with impatience (implying that if you haven't adopted Git or tests or CI pipelines, you are simply being unprofessional). This attitude mistakes domain-specificity for universality. The norms of software engineering evolved to solve software engineering's particular problems: large teams, external customers, requirements testing, huge code-bases, long product lifespans, formal release cycles. These are not the universal conditions of all technical computing.
The tools themselves could (and should!) be better tailored for non-programmer audiences, not just in tutorials and onramps, but in their interfaces, defaults, and documentation. Until that happens, the burden of translation falls entirely on the reluctant developer: and it's worth at least naming that as an unfairness, not just a skills gap to be closed.
Thanks again. This is very insightful and resonates strongly.
It took me a while to get to reading this (see what I did there), but your points resonate with me. Some input from me, I actually have become way more disciplined about "developer stuff" thanks to GenAI. I used to be lazy about tests, specs, and docs. These are such a low bar now, you have to be actively avoiding them. And, I have found out that if you write clear specs and promps, you get much better. So, over three years of learning how to get the best from GenAI output, I have also learned that solid software engineering discipline pays off. Imagine. Ha.
I'm having a similar experience. It's also incredible to reflect on how the role of gen AI has changed as I've adopted these workflows. A few years ago I was psyched when ChatGPT explained a concept to me that I was struggling to understand. A year ago I was psyched when MS Copilot converted a GitHub CI YML file to one I could use with Gitlab. This year, Claude is writing all of my tests and documentation. Oh, and my MATLAB code, too ...
Sign in to participate
