But a university (or a department) could manage a centralized set of software developers who get assigned to different lab projects over time. If Professor A's

But a university (or a department) could manage a centralized set of software developers who get assigned to different lab projects over time. If Professor A's grant goes away, then you just pick up more work on Professor B's grant and Professor C's -- all of which would be managed by the university or department, and not separately managed by each of the professors. Universities already do this for essential services like janitorial work, administrative work, and centralized IT provisioning, like university-wide email or supercomputing infrastructure. They even already try to do this to some degree with software. For example, there's been a lot of software-focused hiring at the Cornell Weill school in New York City, and some political science research groups at NYU banded together to hire some big data and development staff to service more than just one professor's line of grant-funded projects. The problem is that they still fundamentally undervalue software labor and look at a programmer as simulatenously a low-level grunt and a wizard. You're a low-level grunt because your opinion isn't supposed to matter as much as a domain expert's opinion and your 'creative' contributions (in terms of expressing the research idea in software) is supposed to be less valuable than the domain experts' creative work in coming up with the ideas in a more abstract sense. But you're also supposed to be a magic wizard because you're supposed to juggle unreasonable and conflicting sets of requirements, overcome fundamental computational complexity hurdles, and take a bunch of crappy copy/paste code that none of the domain experts are interested in properly refactoring, and somehow make all of that work correctly, reproducibly, and acceptably fast all in time for various paper and reviewer deadlines.