The other impediment to software engineering research
In the decades since structured programming, many of the advances in software engineering have come out of non-university sources, mostly of four kinds:
- Start-up technology companies (who played a large role, for example, in the development of object technology).
- Industrial research labs, starting with Xerox PARC and Bell Labs.
- Independent (non-university-based) author-consultants.
- Independent programmer-innovators, who start open-source communities (and often start their own businesses after a while, joining the first category).
Academic research has had its part, honorable but limited.
Why? In earlier posts [1] [2] I analyzed one major obstacle to software engineering research: the absence of any obligation of review after major software disasters. I will come back to that theme, because the irresponsible attitude of politicial authorities hinders progress by depriving researchers of some of their most important potential working examples. But for university researchers there is another impediment: the near-impossibility of developing serious software.
If you work in theory-oriented parts of computer science, the problem is less significant: as part of a PhD thesis or in preparation of a paper you can develop a software prototype that will support your research all the way to the defense or the publication, and can be left to wither gracefully afterwards. But software engineering studies issues that arise for large systems, where “large” encompasses not only physical size but also project duration, number of users, number of changes. A software engineering researcher who only ever works on prototypes will be denied the opportunity to study the most significant and challenging problems of the field. The occasional consulting job is not a substitute for this hands-on experience of building and maintaining large software, which is, or should be, at the core of research in our field.
The bodies that fund research in other sciences understood this long ago for physics and chemistry with their huge labs, for mechanical engineering, for electrical engineering. But in computer science or any part of it (and software engineering is generally viewed as a subset of computer science) the idea that we would actually do something , rather than talk about someone else’s artifacts, is alien to the funding process.
The result is an absurd situation that blocks progress. Researchers in experimental physics or mechanical engineering employ technicians: often highly qualified personnel who help researchers set up experiments and process results. In software engineering the equivalent would be programmers, software engineers, testers, technical writers; in the environments that I have seen, getting financing for such positions from a research agency is impossible. If you have requested a programmer position as part of a successful grant request, you can be sure that this item will be the first to go. Researchers quickly understand the situation and learn not even to bother including such requests. (I have personally never seen a counter-example. If you have a different experience, I will be interested to learn who the enlightened agency is. )
The result of this attitude of funding bodies is a catastrophe for software engineering research: the only software we can produce, if we limit ourselves to official guidelines, is demo software. The meaningful products of software engineering (large, significant, usable and useful open-source software systems) are theoretically beyond our reach. Of course many of us work around the restrictions and do manage to produce working software, but only by spending considerable time away from research on programming and maintenance tasks that would be far more efficiently handled by specialized personnel.
The question indeed is efficiency. Software engineering researchers should program as part of their normal work: only by writing programs and confronting the reality of software development can we hope to make relevant contributions. But in the same way that an experimental physicist is helped by professionals for the parts of experimental work that do not carry a research value, a software engineering researcher should not have to spend time on porting the software to other architectures, performing configuration management, upgrading to new releases of the operating system, adapting to new versions of the libraries, building standard user interfaces, and all the other tasks, largely devoid of research potential, that software-based innovation requires.
Until research funding mechanisms integrate the practical needs of software engineering research, we will continue to be stymied in our efforts to produce a substantial effect on the quality of the world’s software.
References
[1] The one sure way to advance software engineering: this blog, see here.
[2] Dwelling on the point: this blog, see here.
Eiffel Software
Home page at ETH
Informatics Europe
LASER summer school
Propulsion Academy
You fail to consider the obvious alternative. Get a job working in an actual software house creating — or, better still — maintaining production software. If you think that hiring developers, testers, etc., to work in an academic environment as a part of a research effort is going to be any more realistic than it will be to have a Ph.D candidate developing software as a part of their thesis effort, you’re mistaken.
You misread my text. I don’t need a job with a software house (if only because I am involved on that side too). Serious software engineering research — we are talking about academia, not industry — should be able to work on real software, not just demos and prototypes.
That sounds as if I meant that you should leave your academic position, sorry. That’s not what I meant. But if you can get a grant to do “field research” as an employee of an ISV — although any company with a software product would do — that would be far preferable to sitting in an office and theorizing about what happens in the real world (not to imply that’s the case with you, either). I think that companies would jump at the opportunity to have a highly trained developer on their staff, effectively (presuming your grant covered some portion of their expenses in taking you on) for free, or very cheaply. And you’d have the opportunity to see how software engineering is carried out in the “real” world.