1. WHAT EVERY SCIENTIST
SHOULD KNOW ABOUT
SOFTWARE
Summary from panel discussion 10/9/2012

2. 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

3. 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.

4. 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.

5. 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)

6. 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?