Research Software Design Tradeoffs

Blog post edited by Anonymous - "Migrated to Confluence 4.0"

After the successes (and setbacks) of our five summer undergraduate research assistants, we finally have a useable ChamView prototype that is based on my concept of an image grammar. My work over the last week or so has been to integrate the students’ work, streamline the software and write a paper highlighting the grammar. The software is being designed for three purposes:

• to create an immediately useable application for observational scientists in domains such as Biology and Psychology
• to provide a programming interface for other researchers to utilize the image grammar framework in their own areas of study
• to support ongoing research experiments by me and my students.

To address the needs of these different audiences, the ChamView software is being developed with the following goals in mind:

• developing programs that are easily usable by scientists with little to no experience in computation
• developing libraries and a framework that are useful, easy to use and easy to expand upon
• developing robust software that can be used to run experiments and generate (publishable) results

Although these goals are not mutually exclusive, they are time consuming and the students have left for the summer. Therefore, I need to prioritize. For instance, I could easily spend a lot of time designing elegant software – and well-designed software should pay off in the long run. However, I also know that software design can be a never-ending process, and at some point it is better to grab at the lowest hanging fruit and work toward a publication.

Of course, a major difficult with constantly chasing after the lowest hanging fruit in order to write the next paper is that I never really get the time to develop the research software into a tool that, I believe, could be foundational to advances in many different areas. My solution is to publish software early and often, while keeping the overarching design goals in mind.

By focusing on developing the next evolution of the software in order to move my experiments forward, I will have the opportunity to use the software and hopefully improve the design over time. With this approach, I need to be willing to rewrite core components when it becomes apparent that they are no long useful – although this is tricky since I also need to establish and maintain a fairly consistent standard for other users to work with.

We will see how well this goes,

• Dirk

View Online

Blogpost migrated from ICER Wiki using custom python script. Comment on errors below.