Software Practice 12 breakout - What Every Scientist Should Know About Software


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Practice 12 breakout - What Every Scientist Should Know About Software

  1. 1. WHAT EVERY SCIENTISTSHOULD KNOW ABOUTSOFTWARESummary from panel discussion 10/9/2012
  2. 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. 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. 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. 5. 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)
  6. 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?