The Crisis in Modern Engineering Computing In my fifteen years as both a practicing mechanical engineer and an engineering educator, I have observed a troubling pattern that has become increasingly prevalent across academia and industry. Consider the case of Vahid, a talented graduate student in our department's turbulence research group. Vahid had spent six months developing a large eddy simulation of flow through a turbine cascade using ANSYS Fluent. He had validated his mesh, tuned his solver settings, and generated results that appeared physically plausible. His advisor was pleased. Then came the question that would expose the fragility of his workflow: “Vahid, can you run this same simulation with a refined mesh and the WALE subgrid model instead of Smagorinsky?” Vahid spent the next two weeks clicking through menus, exporting and importing files, and manually adjusting parameters. He made three transcription errors that invalidated his initial results. When he finally obtained reasonable data, he realized he had forgotten to record exactly which combination of settings produced which output. His workflow was not reproducible. His frustration was not with physics, nor with the software's computational capabilities, but with the fundamental mismatch between how the software was designed and how engineering actually works. This is not Vahid's failure. It is a failure of our engineering software paradigm a paradigm that prioritizes visual interfaces over reproducibility, monolithic applications over composable tools, and point-and-click operation over automation.