WHAT EVERY SCIENTIST SHOULD KNOW ABOUT SOFTWARE

Summary from panel discussion 10/9/2012

What every scientist should know

  Know that you don’t know everything.   Just as no one would expect to know everything about all of

say chemistry, or even everything about a much narrower topic, no one knows everything about computer science and software engineering. Know when to learn more and when to bring in others.

  How to write automated tests.  With a good set of tests, developers can confidently fix

problems without introducing new ones and clean up code.   Even if it isn’t easy due to lacking testing framework, do it

anyway.   Version control.

  If a change breaks something, can go back  Can reproduce an run on an earlier version of code

What every scientist should know, ctd

  How to recognize what clean code looks like.   Every project needs a domain model that defines

nomenclature, etc. This should used consistency in project.   Realize that software embodies structure and information

beyond code   If this is explicitly recognized and documented, the design

will be better   It will be easier for future developers to maintain the

software   Up front effort for sustainability is worth the effort.

What every scientist should know, ctd.

  Sufficient documentation is crucial for future users/maintainers of the code—including themselves.   Documentation can take forms other than comments and manuals.   Well designed code that is consistent with a domain model can be

largely “self-evident”   Tests provide documentation as well

  How to debug   Understand the process   Be aware and know how to use tools (debuggers, valgrind)

  How to know when to scale up (larger memory, parallel machine, larger development effort)

  To be aware of available tools and use when appropriate   visualization

  That code is the means not the end. Don’t be too possessive about it.

How teach good software development practices to scientists   Use domain specific materials and examples   Organizing courses in small chunks over a longer

period of time is better than intensive courses (but may not be possible)

  Even better, integrate software instruction into science courses.

  Try to get them early before indoctrinated with bad habits.

  Pair programming with mentor is good way to learn (but highest productivity when partners are equal)

Community

 The community needs to value software development.  This needs to be expressed in some form of

“academic currency” so that scientists get credit for high quality software development.

 It should be valued as much as, say, developing a new experimental method

 SC competitions encourage poor practices. Are they worth it?