This month sees the publication of our article “Software Design for Empowering Scientists” in IEEE Software (IEEE Explore; DOI). It was fun to write. Basically it tells the story of the principles that we used in delivering the Taverna scientific workflow workbench (56,000 downloads and counting) and how we applied them to the myExperiment virtual research environment. Which is interesting, because Taverna is software you install on your PC while myExperiment is a Web 2.0 site – quite different beasts.
I’m looking forward to seeing how this article goes down. Already it’s upset some computer scientists. I gave a lecture on it to my 3rd year class and there were protests that I was “saying the opposite to other lecturers”. It wasn’t just that I dared suggest that Web 2.0 isn’t hype but rather is a well-defined set of observed design patterns. Worse, I advocated the perpetual beta and – outrageously – I suggested that sometimes doing the specific is important over the generic…
This goes against the established wisdom in Computer Science. We train our computer scientists and software engineers to elicit requirements, design, build, test, deploy. We teach abstraction, and install in them (sic) an imperative toward the generic. Which is fine in certain situations, but in e-research it can be a formula for delivering a solution to a problem our users didn’t know they had and perhaps never will.
Tell me if you disagree! 
-
I think I tend to disagree with the blog title. The paper is less strong on this. Overlooking the six principles of design (for adoption) listed in the paper, discuss underlying principles of prototyping. Prototyping itself is a well-known software design approach, but certainly not the only one, nor ‘good science’.
Instead, the prototyping works well for Taverna because bench scientists in natural sciences typically have zero knowledge of software design. And each feature you add makes them wonder if something else was possible too. It is practically difficult, if not impossible, to write a proper requirement analysis with these scientists. I disagree that that makes the Taverna model ‘good science’.
From my perspective as Taverna1 and since a few days Taverna2 plugin developer, my interest in Taverna is not the design. I find Taverna1 in particular really difficult to use. For me the most important reason to like Taverna is the liberal license, and I find it a shame the role of the license is not mentioned in the list of design principles.
This gets me to what I think these design principles in the article are about. Not about software design, but about ‘good community building’. Clearly, this is an underlying idea, with MyExperiment.org in mind too.
In short, I had rather see the blog and paper titles say ‘Project Design for Empowering Scientists”.
-
Thanks for this feedback and I think you make two very good points…
The paper is indeed about the project design and the software design process. A paper about the actual design of the software might be a bit different – for example we have an ongoing discussion in the team about artificially introducing complexity in a SOA by factoring out services in pursuit of open science (one day we’ll write that paper!) I think the title is ok in the software engineering context of the IEEE Software magazine (it was rewritten during copyediting!) but the title you suggest is valid too.
I realise now that the title of the post does need explanation, which means it’s not the best title! It’s actually a slogan from one of my talks, and it refers to the observation that computer scientists always seem to make things more complicated – to which I point out that Good Computer Science Makes Things Easier. I am going to edit the post to reflect this. Thank you!
2 comments
Comments feed for this article
Trackback link: http://blog.openwetware.org/deroure/wp-trackback.php?p=34