More Irish Countryside Adventures!
SW Architecture Workshop Summary
Wearable and Pervasive Computing
We Don't Get No Respect! (Panel)
Window on the World
Issue 2
Why Don’t Software Engineers Get Any (Self) Respect?
By Mike Wing
Software engineers have the problem that our work seems boring and that research doesn’t seem to make any difference. We don’t have anything like the pretty pictures of faraway galaxies that physicists use to capture the imagination of the public. This perception is a problem for researchers who want to prove to funding agencies that their work will pay off. This is a problem for practitioners who want more than a reputation for being drudges.
Anecdotally, software engineers seemed willing to take the blame for the Y2K problem, if it came to be a crisis, but seemed unwilling to take the credit for the Internet. Leon Osterweil stood up in cheerleading mode and argued that software engineers need to stand up for their own successes, and think well of themselves, so that others will, too. When society pushes software engineers, we need to push back.
The Panel
Leon Osterweil began by listing several myths about software engineering research: that software engineering research has little impact on practice, has made little productivity gains, and is a poor investment; and that industry leads while the research community follows.
He then listed several facts about software engineering research. Software engineering problems are hard, fundamental, and enduring. Software engineering researchers are improving their grips on these problems. Software engineering practice has made orders of magnitude gains. And, software engineering research helps practice. (Later, Barry Boehm argued that software engineering needs constant reinventing, and so the problems are perhaps not that enduring.)
In his talk, Barry Boehm gave a brief history of cost estimation, from the earliest projects in 1965, to many projects in the 1980s that are still being used, to ongoing projects today. He used two diagrams to show progress is interpreted against software engineers. In the first, "lines of code per year" appeared unchanging. But "lines of code in service" compares favourably with transistors shipped.
Volker Gruhn talked about process models. Among the achievements are the realization that process models are used for multiple purposes: documentation, analysis, enactment, and process improvement, that there are degrees of strictness, and that there are various degrees of enaction support. There has been transfer of knowledge from software process research to the workflow research community. And, the research is available for transfer into operational software too, even though it is not widely used.
Jeff Kramer spoke about model building. He pointed out that almost all software is model building and that models are ubiquitous. Lots of progress has been made.
Edward Miller spoke about testing. Some areas have made good progress, but others have been ignored. He related that, as a reviewer, he had a hard time getting projects approved at the NSF that he considered important.
Frank Anger (substituting for Mike Evangelist) spoke from the point of view of an NSF program manager. He claimed to have two jobs: first, to get, winnow, and manage good research proposals; second, to explain to managers, politicians, oversight committees, the media, and others that software engineering research matters. To sell software engineering effectively, the political leadership needs good sound bites. Unfortunately, improved regression analysis lacks the gripping imagination that nano-technologists get when they propose to tether a satellite to the earth with a polymer. And, some people in computer science view software engineering as useless.
To help sell software engineering, supporters should give talks about what they do, write articles for non-technical publications, write op-ed pieces, and participate in NSF workshops. And, please send copies of everything to Frank at fanger@nsf.org.
Designer
and Webmistress
Caroline Kehoe