Designing Software for Scientists

Creating a software design for scientists can be tricky business. Unlike the businessman, who is better off looking at the pretty database report or marveling over the catchy name of the latest Forms over Data application, the scientist can actually contribute to the implementation – provided you use the right architecture. In year’s past (I’m referring to 20+ years ago), the typical Physicist / Chemist / etc. was nearly on par with the typical software engineer / computer scientists with respect to software design skills. Although the scientific community of that time preferred the ‘GOTO’, they nevertheless understood the value of using subroutines to nearly the same degree as a computer scientists.

Not so, today. Software design has come a long way since then.

Software Design has Matured

Software design has matured. We have terms like inheritance and encapsulation. We talk about singletons, abstract factories, and chain of responsibility. We use terms like polymorphism, covariance, and contravariance (as applied to software design). We compose systems with Inversion of Control containers. Mock objects are used for unit testing. Reflection, dynamic and static languages. The discipline of software engineering has matured to a point where the typical scientist cannot possibly hope to understand what makes a well-design system – no more than a software engineer can understand how to model protein folding of polypeptides.

So how do we design software so that other scientists and engineers can participate in the implementation? Here are some ideas.

1. Keep it Simple.

Don’t compose in an IoC container – too abstract. Do use layers, repositories, and multiple program units. Scientists understand process control, state transitions, and other engineering/scientific/mathematics concepts so use them in your software designs. [Object models? Not sure where I stand on this one. There might be a whole blog post in here somewhere.]

2. Work in Pairs

Match a subject matter expert with a software design expert.

3. Limit Participation

Limit the “coding” performed by the scientist to the functional code, not the design. The infrastructure, layout, program flow as well as all meta-design elements (project structure, build environment, coding standards, etc.) – essentially the software design, should be strictly the realm of the software architect. Leave the algorithms for the subject matter expert.

4. Move the problem domain.

Let the scientists program in their own “language” - provide a scripting component, meta-programming, or data-driven model such that the subject matter expert remains closer to their problem domain, even if this means additional software (such as interpreters, data transformation engines) must be developed. In a really large system, you might go so far as to develop a rules engine or other knowledge base approach.

5. Use Abstractions

The nature of software is to provide abstractions. This also happens to be common of all science and engineering. You can use your entire software design Bag ‘o Tricks provided you supply an appropriate level of abstraction over top. Explain the abstraction, and the typical scientist will have no trouble using it, even if they really don’t know what is going on. So in spite of the first idea listed here, you can fire up your favorite IoC container and use it – as long as you provide the right abstraction for your scientific colleagues.