Software Practice 12 breakout - What Every Scientist Should Know About SoftwarePresentation Transcript
WHAT EVERY SCIENTISTSHOULD KNOW ABOUTSOFTWARESummary 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 developmentpractices 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?