Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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


Published on

  • Be the first to comment

  • Be the first to like this

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?