In times when people are more and more starting to crossover across different disciplines one of the main difficulties we have to face is communication.

Different mindsets, perspectives and goals are the obvious obstacle when exploring a problem from different backgrounds. Of course all of this comes also with opportunity for improvement since we can gain new insights while looking at things from different angles. 

Here at OpenWorm we like to crossover across different disciplines and the more the project moves forward the more this is becoming our bread and butter. The main area of crossover is between software engineers and scientists, in particular neuroscientists, physicists, biologists. In the many discussions we have taken part to one of the main topics when things start to get confusing is modelling.

When in two different domains the same word is used with different meanings things start to be confusing and scientists and software engineers have a very different concept attached to the word “model”. 

In science a model is very often a mathematical model, defined by a set of equations that determine how a system changes from one state to the next and how one variable depends on the the value of other variables. In science models are used to simplify reality and make predictions about the real world.

In software engineering we have a completely different story. Since the beginning of computer programming a program is divided in two parts: program code and data. Program code is a set of instructions that details the task that the computer has to perform. Data is what you will be performing these tasks onto. You can have a program that shuffles your address book and you can have another one that sorts it in alphabetical order. Shuffling and sorting are two programs, the address book itself is the data. So when do models come into play? It’s just one step ahead: in software engineering a model is basically always a data model. A model explicitly determines the structure of data. And data usually do not represent programs.

On top of this there is the usual confusion within the software engineering world itself between Models and MetaModels. MetaModels define the structure of a Model, while the Model is the data itself. If we were working in XML the MetaModel would be the schema and the Model would be the XML file itself. The reason why this generates a confusion is that MetaModel is -unfortunately- often shortcut to just “model”.

So how do the worlds of engineers and scientists collide?

If a software engineer were to ask both Ptolemy and Newton to show him the “model” he would expect from both the same thing: data;  two files or a DB (probably would be happy to get away with two XMLs) describing position and mass of every celestial body. How do they move? He wouldn’t care about that if he’s asking about the model. 

While both Ptolemy and Newton would just show you some paper with their ideas if you were to ask a scientist today to show you their model you would be presented with code, tons of it, most likely in some scripting language, whose structure wouldn’t differ much from the notes of Ptolemy.

Without data and program separation it is just not possible to design any software. As much as a bunch of variables declared in your global scope followed by instructions that determine what operations to perform on those variables can do well when writing up an academic thesis that is just not going to work out when we want to build reusable and maintainable software.

Exciting times are ahead and the sooner we’ll learn how to join our expertise in building software with our scientific knowledge the earlier we’ll be able to reach for the stars. Or in silico worms.

6science, software-engineering,