{"id":1999,"date":"2010-11-16T17:23:10","date_gmt":"2010-11-16T22:23:10","guid":{"rendered":"http:\/\/www.easterbrook.ca\/steve\/?p=1999"},"modified":"2010-11-17T19:20:58","modified_gmt":"2010-11-18T00:20:58","slug":"you-cant-delegate-ill-defined-problems-to-software-engineers","status":"publish","type":"post","link":"https:\/\/www.easterbrook.ca\/steve\/2010\/11\/you-cant-delegate-ill-defined-problems-to-software-engineers\/","title":{"rendered":"You can’t delegate ill-defined problems to software engineers"},"content":{"rendered":"

I had lunch last week with Gerhard Fischer<\/a> at the University of Colorado. Gerhard is director of the center for lifelong learning and design, and his work focusses on technologies that help people to learn and design solutions to suit their own needs. We talked a lot about meta-design, especially how you create tools that help domain<\/em> experts (who are not necessarily software<\/em> experts) to design their own software solutions.<\/p>\n

I was describing some of my observations about why climate scientists prefer to write their own code rather than delegating it to software professionals, when Gerhard put it into words brilliantly. He said “You can’t delegate ill-defined problems to software engineers”. And that’s the nub of it. Much (but not all) of the work of building a global climate model is an ill-defined problem. We don’t know at the outset what should go into the model, which processes are important, how to simulate complex physical, chemical and biological processes and their interactions. We don’t know what’s computationally feasible (until we try it). We don’t know what will be scientifically useful. So we can’t write a specification, nor explain the requirements to someone who doesn’t have a high level of domain expertise. The only way forward is to actively engage in the process of building a little, experimenting with it, reflecting on the lessons learnt, and then modifying and iterating.<\/p>\n

So the process of building a climate model is a loop of build-explore-learn-build. If you put people into that loop who don’t have the necessary understanding of the science being done with the models, then you slow things down. And as the climate scientists (mostly) have the necessary \u00a0technical skills, it’s quicker and easier to write their own code than to explain to a software engineer what is needed. But there’s a trade-off: the exploratory loop can be traversed quickly, but the resulting code might not be very robust or modifiable. Just as in agile software practices, the aim is to build something that works first, and worry about elegant design later. And that ‘later’ might never come, as the next scientific question is nearly always more alluring than a re-design. Which means the main role for software engineers in the process is to\u00a0do\u00a0cleanup operations<\/a>. Several of the software people I’ve interviewed in the last few months at climate modeling labs described their role as mopping up after the parade (and some of them used more colourful terms than that).<\/p>\n

The term meta-design<\/em> is helpful here, because it specifically addresses the question of how to put better design tools directly into the hands of the climate scientists. Modeling frameworks<\/a> fit into this space, as do domain specific-languages<\/a>. But I’m convinced that there’s a lot more scope for tools that raise the level of abstraction, so that modelers can work directly with meaningful building blocks<\/a> than lines of Fortran. And there’s another problem. Meta-design is hard. Too often it produces tools that just don’t do what the target users want. If we’re really going to put better tools into the hands of climate modelers, then we need a new kind of expertise<\/a> to build such tools: a community of meta-designers who have both the software expertise and the domain expertise in earth sciences.<\/p>\n

Which brings me to another issue that came up in the discussion. Gerhard provided me a picture that helps me explain the issue better (I hope he doesn’t mind me reproducing it here; it comes from his talk\u00a0“Meta-Design and Social Creativity<\/a>” given at IEMC 2007):<\/p>\n

\"\"<\/a>

To create reflective design communities, the software professionals need to acquire some domain expertise, and the domain experts need to acquire some software expertise (diagram by Gerhard Fischer)<\/p><\/div>\n

Clearly, collaboration between software experts and climate scientists is likely to work much better if each acquires a little of the other’s expertise, if only to enable them to share some vocabulary to talk about the problems. It reduces the distance between them.<\/p>\n

At climate modeling labs, I’ve met a number both kinds of people – i.e. climate scientists who have acquired good software knowledge, and software professionals who have acquired good climate science knowledge. But it seems to me that for climate modeling, one of these transitions is much easier than the other. It seems to be easier for climate scientists to acquire good software skills than it is for software professionals (with no prior background in the earth sciences) to acquire good climate science domain knowledge. That’s not to say it’s impossible, as I have met a few people who have followed this path (but they are rare). It seems to require many years of dedicated work. And there appears to be a big disincentive for many software professionals, as it turns them from generalists into specialists. If you dedicate several years to developing the necessary domain expertise in climate modeling, it probably means you’re committing the rest of your career to working in this space. But the pay is lousy, the programming language of choice is uncool, and mostly you’ll be expected to clean up after the parade rather than star in it.<\/p>\n","protected":false},"excerpt":{"rendered":"

I had lunch last week with Gerhard Fischer at the University of Colorado. Gerhard is director of the center for lifelong learning and design, and his work focusses on technologies that help people to learn and design solutions to suit their own needs. We talked a lot about meta-design, especially how you create tools that […]<\/p>\n","protected":false},"author":392,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,31],"tags":[],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/www.easterbrook.ca\/steve\/wp-json\/wp\/v2\/posts\/1999"}],"collection":[{"href":"https:\/\/www.easterbrook.ca\/steve\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.easterbrook.ca\/steve\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.easterbrook.ca\/steve\/wp-json\/wp\/v2\/users\/392"}],"replies":[{"embeddable":true,"href":"https:\/\/www.easterbrook.ca\/steve\/wp-json\/wp\/v2\/comments?post=1999"}],"version-history":[{"count":3,"href":"https:\/\/www.easterbrook.ca\/steve\/wp-json\/wp\/v2\/posts\/1999\/revisions"}],"predecessor-version":[{"id":2005,"href":"https:\/\/www.easterbrook.ca\/steve\/wp-json\/wp\/v2\/posts\/1999\/revisions\/2005"}],"wp:attachment":[{"href":"https:\/\/www.easterbrook.ca\/steve\/wp-json\/wp\/v2\/media?parent=1999"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.easterbrook.ca\/steve\/wp-json\/wp\/v2\/categories?post=1999"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.easterbrook.ca\/steve\/wp-json\/wp\/v2\/tags?post=1999"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}