Engineering for research is a different job
Lessons from building NIH-funded platforms where the requirements are hypotheses, not specs.
I’ve spent the last few years building software inside university research labs — first at the Hawaii Digital Health Lab, now leading engineering at the UCSF TECH Lab. The work looks like product engineering from the outside. It isn’t.
Requirements are hypotheses
In product, a requirement is a decision someone made. In research, a requirement is a question someone is trying to answer, and the answer may invalidate the feature. A study protocol changes because a pilot showed the task was too hard for participants. A data collection scheme changes because the analysis needs a signal nobody anticipated.
The engineering response isn’t to demand stability. It’s to build systems where the expensive parts — the real-time audio/video stack, the session infrastructure, the tracking pipeline — stay fixed while the experimental surface stays cheap to change. On our platform, the multiplayer games are effectively plugins. Swapping the study task shouldn’t mean touching the transport layer.
Instrumentation is the product
For a diagnostic platform, the interaction is the data. What we capture during a session — timing, turn-taking, engagement signals — is the entire scientific output. That inverts the usual priority: telemetry isn’t an operational afterthought, it’s the primary artifact, and it deserves the same design rigor as any user-facing feature.
You are also teaching
A meaningful part of my role is mentoring students through UCSF’s Undergraduate Research Apprentice Program. Research teams turn over on academic calendars, not on tenure. That reality argues for the same things good engineering culture argues for anyway — readable code, honest documentation, small well-scoped contributions — but with much less slack. A codebase that only makes sense to the person who wrote it has a lifespan of about one semester.
The tradeoff worth naming
Research software carries technical debt that would be unacceptable in a commercial product, and that’s often correct. The half-life of an experimental feature might be six weeks. Investing in its architecture is waste. The skill is knowing which parts are the experiment and which parts are the instrument — and holding a very different quality bar for each.