NSF workshop: ideas wanted
I got invited to a National Science Foundation workshop whose…
goal broadly speaking will be to reflect on software
engineering research and practice of the past, to determine some areas
in which “rethinking” is needed, and to engage in some rethinking.
I have a position (strongly held, of course). But when I look at the list of attendees and their affiliations, I worry that I may be the only person there representing, well, you: the kind of person who reads this blog or (especially) follows me on twitter. So I’d like to hear what you think needs rethinking. (Please include a tiny bit about what kind of person you are. Something like “rails developer in boutique shop”.) You can reply here, via email, or by responding to my tweet on the subject.
My basic position goes something like this:
Twenty years ago, the self-conception of the software engineering researcher went something like this, I think:
I am a scientist, though partly of the applied sort, discovering important principles which engineers will then put into practice when building systems. I aspire to be something like the Charles Darwin of The Origin
I think the world has moved on from that. What was once an intellectual structure that could be considered built has since exploded into something more like a genuine ecosystem. There are vast numbers of people, communicating in all kinds of strange ways, assembling practically innumerable pieces of software in scrapheap ways, collaborating—quite often across organizational boundaries—in a way more reminiscent of a rhizome than a command-and-control tree.
The appropriate response to that is to go back in time before The Origin to the Charles Darwin who spent eight years studying barnacles, grasping their differences, and publishing the definitive work on them. There is a lot to study in the software development ecosystem (which, note especially, will require collaboration with researchers who know more about people and groups than context-free grammars).
Time to switch from Alan Kay’s glamorous “the way to predict the future is to create it” to something more in keeping with Kuhn’s normal science: the world is out there; mine it for deep knowledge and extensive data (against, I hope, the background of the “paradigms” used by practitioners).
July 15th, 2009 at 9:57 am
I think your last paragraph is the point to emphasize, given the way you describe the possible panel participants, since it draws on some recognized authority.
Perhaps going back to the original NATO papers (from both conferences) as well as Royce’s paper (and what he really said) might help as well since they both seem to be misinterpreted and/or reported today.
There is also the work presented at the Empirical Studies of Programmers workshops that discussed a lot about how people understand software.
July 15th, 2009 at 10:36 am
Responding to your appeal via twitter:
I am a departmental manager in an engineering and product development company established for 40 years. I manage a team of software engineers and consultants, working on informatic systems for finance, media and manufacturing clients. The company also engineers consumer goods, medical devices, and other products for various industries. We are product development engineers, not manufacturers.
I want software engineering research to proceed from an understanding of the known properties of computer software considered as an “engineering material”, rather than from an aspiration to be like (a largely imagined vision of) engineering disciplines based on dramatically different materials. Software is a relatively new material and its properties have taken a while to become clear, particularly as the constraints placed on software engineering activities by the underlying hardware have relaxed. Processing power and memory is now abundantly available to software engineers, so their work is no longer overwhelmingly dominated by the need to work around limitations of the physical interface to their work-piece.
Successful software engineering projects exist, what they do should be captured and made widely known even if it does not seem to be aligned with what one might “expect” (or want) to be successful. Previous attempts to do that over the past half-century have consistently been rejected by vociferous parties, sometimes within industry but most especially within academia. For the good of the discipline this tendency must end.
Most software engineering projects under-deliver in one or more respects. This is often brought about by management expectations and demands that are in conflict with the properties of software as an engineering material. Purchasers and managers of software engineering effort must be educated to plan, track and operate such projects in alignment with what is known to work in sympathy with the properties of software. This is not entirely their fault, they have been misinformed by the vociferous parties mentioned before.
July 15th, 2009 at 11:31 am
Keith’s comments remind me of Brook’s “essence and accidents” paper and the need to see how people try to deal with software’s complexity, including how (and why) such approaches are successful, or not. This was one of the concerns of the Empirical Studies of Programmers workshops.
The latter leads me to Petroski’s (and others’) comments about how engineering learns and grows through learning from and response to failure. The software field seems to avoid such study because it appears to be able to dodge visibility in ways other engineering disciplines do/can not (perhaps due to understandable fears of litigation and market negativity).
July 15th, 2009 at 1:09 pm
[…] an example of what I meant by my earlier position. Suppose I were a professor and someone wanted to do a PhD under me. He or she is sort of […]