Internal software is frequently described as successful when it ships. For scientific software, shipping is only the beginning. The real test is whether the tool becomes part of the scientist’s normal reasoning loop.
Trust is a systems property
Users trust a tool when they can understand where data came from, recover from mistakes, inspect intermediate results, and predict what the system will do next. Those properties come from architecture.
Latency changes behavior
If a workflow takes too long, users build side channels: spreadsheets, local scripts, copied files, screenshots, or manual notes. Performance is therefore not only a technical concern. It changes the organization’s data topology.
Design for the exception path
Scientific work contains ambiguity. The system has to make it easy to flag uncertainty, annotate edge cases, preserve context, and return to the main workflow. If exception handling lives outside the tool, adoption will eventually live outside the tool too.
Measure the right thing
Usage counts are useful, but behavior is better. Measure repeat usage, time to complete the job, manual work displaced, error recovery, overrides, and whether users return to old workflows. Adoption tells you whether architecture matches reality.