Software Practice 12 breakout - What Every Scientist Should Know About Software
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 1,199 views

 

Statistics

Views

Total Views
1,199
Views on SlideShare
412
Embed Views
787

Actions

Likes
0
Downloads
2
Comments
0

2 Embeds 787

http://astrocompute.wordpress.com 786
http://beforeitsnews.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software Practice 12 breakout - What Every Scientist Should Know About Software Software Practice 12 breakout - What Every Scientist Should Know About Software Presentation 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?