Speaker
Description
Why does the development of scientific software often deviate from robust software engineering standards? Reflecting on the motivations behind each reveals the tacit route to what is deemed successful software. Industry software is typically designed for scalability, stability, and broad applicability, while scientific software prioritizes adaptability, exploration, and domain-specific insight for a smaller, expert user base. Reduction sits at a crossroads where strict standards must be met to achieve facility goals, but the process is still required to grow with the community.
This poster will examine the merits of each approach when developing a standardized software for facility end users. It will assert where standard engineering practices should remain firm--reproducibility, provenance, and transparency--and where flexibility is required to not stifle the scientific process, such as workflow flexibility, and facets for exploration. Drawing on experience with SNAP reduction, I highlight real examples how each approach either succeeded or failed to achieve facility goals.
I further argue that many recurring “software problems” are fundamentally social, arising from fragmented collaboration and lack of consensus rather than technical limitations. Rather than proposing a global solution, I present practical design strategies for building systems that remain robust and usable in the presence of ongoing methodological divergence.
