I went to a workshop earlier this week on “the Future of Software Engineering Research” in Santa Fe. My main excuse to attend was to see how much interest I could raise in getting more software engineering researchers to engage in the problem of climate change – I presented my paper “Climate Change: A Software Grand Challenge“. But I came away from the workshop with very mixed feelings. I met some fascinating people, and had very interesting discussions about research challenges, but overall, the tone of the workshop (especially the closing plenary discussion) seemed to be far more about navel-gazing and doing “more of the same”, rather than rising to new challenges.

The break-out group I participated in focussed on the role of software in addressing societal grand challenges. We came up with a brief list of such challenges: Climate Change; Energy; Safety & Security; Transportation; Health and Healthcare; Livable Mega-Cities. In all cases, we’re dealing with complex systems-of-systems, with all the properties laid out in the SEI report on Ultra-Large Scale Systems - decentralized systems with no clear ownership; systems that undergo continuous evolution while they are being used (you can’t take the system down for maintenance and upgrades); systems built from heterogeneous elements that are constructed at different times by different communities for different purposes; systems where traditional distinctions between developers and users disappear, as the human activity and technical functionality intertwine. And systems where the “requirements” are fundamentally unknowable – these systems simultaneously serve multiple purposes for multiple communities.

I’ve argued in the past that really all software is like this, but that we pretend otherwise by drawing boundaries around small pieces of functionality so that we can ignore the uncertainties in the broader social system in which it will be used. Traditional approaches to software engineering work when we can get away with this game – on those occasions when it’s possible to get local agreement about a specific set of software functions that will help solve a local problem. The fact that software engineers tend to insist on writing a specification is a symptom that they are playing this game. But such agreements/specifications are always local and temporary, which means that software built in this way is frequently disappointing or frustrating to use.

So, for societal grand challenge problems, what is the role of software engineering research, and what kinds of software engineering might be effective? In our break-out group, we talked a lot about examples of emergent successful systems such as Facebook and Wikipedia (and even the web itself), which were built not by any recognizable software development process, but by small groups of people incrementally adding to an evolving infrastructure, each nudging it a little further down an interesting road. And by frequently getting it wrong, and seeking continual improvement when things do go wrong. Software innovation is then an emergent feature in these endeavours, but it is the people and the way they collaborate that matters, rather than any particular approach to software development.

Obviously, software alone cannot solve these societal grand challenges, but software does have a vital role to play: good software infrastructure can catalyze the engagement of multiple communities, who together can tackle the challenges. In our break-out group, we talked specifically about healthcare and climate change – in both cases there are lots of individuals and communities with ideas and enthusiasm, but who are hampered by socio-technical barriers: lack of data exchange standards, lack of appropriate organizational structures, lack of institutional support, lack of a suitable framework for exploratory software development, tools that ignore key domain concepts. It seems increasingly clear that typical governmental approaches to information systems will not solve these problems. You can’t just put out a call for tender and commission construction of an ultra-large scale system; you have to evolve it from multiple existing systems. Witness repeated failures of efforts around shared health records, carbon accounting systems, etc. But governments do need to create the technical infrastructure and nurture the coming together of inter-disciplinary communities to address these challenges, and strategic funding of trans-disciplinary research projects is a key element.

But what was the response at the workshop to these issues? The breakout groups presented their ideas back to the workshop plenary on the final afternoon, and the resulting discussion was seriously underwhelming. Several people (I could characterize them as the “old guard” in the software engineering research community) stood up to speak out against making the field more inter-disciplinary. They don’t want to see the “core” of the field diluted in any way. There were some (unconvincing) arguments that software engineering research has had a stronger impact than most people acknowledge. And a long discussion that the future of software engineering research lies in stronger ties between academic and industrial software engineering. Never mind that increasingly, software is developed outside the “software industry”: e.g. open source projects, scientific software, end-user programmers, community engagement, and of course college students building web tools that go on to take the internet world by storm. All this is irrelevant to the old guard – they want to keep on believing that the only software engineering that matters is that which can be built to a specification by a large software company.

I came away from the workshop with the feeling that this community is in the process of dooming itself to irrelevancy. But then, as was pointed out to me over lunch today, the people who have done the best under the existing system are unlikely to want to change it. Innovation in software research won’t come from the distinguished senior people in the field…

6 Comments

  1. The outcome is disappointing. In some ways, it’s no wonder that software engineering is still so immature and not meeting the demands of users – actual and potential – if the predilection is, as you say, “that which can be built to a specification by a large software company.”

    There’s way more interesting and really hard problems out there that could be addressed with the skills and expertise of software engineers, rather than just making Excel better or some OS more nifty.

  2. Pingback: Tweets that mention The future of Software Engineering? | Serendipity -- Topsy.com

  3. Software engineering of the old was founded from concepts forged from building things like software for controlling rocket boosters. Today, most software is for users. That talk about software projects failing or being late and over budget was perhaps better explained by just a whole but of stupid ideas that had no market.

    But there is hope (if not from the research community). I’ve seen the US military (yes of all people!) successfully use agile methods to deploy software used in over 600 squadrons of the air force for 10 years. This includes at 3 large corporations with over 100 developers working on this one project/codebase.

    When I’ve visited places like google, its pure chaos in mostly a good way. Free for-all check-outs, very goal driven development.

    The “old problems” of software engineering are mostly manageable today. For research to be relevant, we must think big and solve big issues.

  4. Wonderful post. The dynamics you describe can arise in quite small systems — I spent two years wrestling with one such, which turned out to be tractable. You will not get anywhere if you put “meeting of minds” in the critical path (as you note). Political issues will be on the critical path, but you need to manage them with a political communication model, not a science/engineering “pursuit of truth” model. Printing the paper for reading at the gym right now.

  5. Steve, great post that leaves very mixed feelings – I’m disappointed to hear that the FSE turned out this way but encouraged to continue into that new research direction.
    @Chris: Great to see the hope – I’m positively surprised about agile in air force and pure chaos at google sounds fun. What is your idea – how can we apply the chaotic and goal-driven research approach? I guess community is another important keyword here.
    @Sam: I think you are right about the need for a political communication model. I have no good idea what this could look like – would you already have ideas on that?

  6. @Birgit: what I meant by “political communication model” was that technical people attempting to lead on such issues should adopt a politically-driven mental model of the communications efforts they intended to make. This is NOT the same as examining the politics of a situation and defining a static happy-talk slogan or approach designed to co-opt the opposition. (Examples from US climate change politics: cap-and-trade / “green jobs” / “efficiency as a matter of national security” have all been adopted as paper-over-the-differences, meet-in-the-middle approaches when key players with opposing agendas don’t want to meet in the middle, and thus have not worked.) Instead, you need to become or find an effective political leader (someone with clout and skills) to champion your cause, and do the political work using political resources. “Political” in this case is context dependent: in a company it might have to do with key players, avoiding blame for bad quarterly results, etc., while in national politics the players and forces will be of different types. But the principles: understanding power, process, constituencies, and potential risks and opportunities, are the same, and have little to do with understanding the science/technology. The latter can tell us what is worth fighting for but not how to fight for it.

  7. @Sam Penrose
    Thanks for the additional explanation. In a nutshell, there is no one-solution-fits-the-whole-topic, because that would be what you called “static happy-talk slogan” and we’ll have to keep politics in mind although many of us scientists/techs prefer to stick to their own domain of expertise (science, technology). Thanks again, I will continue thinking about what that could signify in my current setting.

  8. Pingback: ICSE: Sustainable Software for a Sustainable World | Serendipity

Join the discussion: