Introduction

  1. Welcome to class
  2. Introductions
    1. self
    2. students
      1. Names
      2. Where from
      3. Interest in class
  3. About class
    1. Schedule
      1. Week 1
        • Computer skills boot camp
        • Data analysis
        • Numerical methods
      2. Week 2
        • Simulations
          • About
          • Running
          • Writing
        • Visualization
        • Final project design
      3. Week 3
        • Building project
        • Running simulation
        • Tour CalIT2
        • Package project
    2. Daily Schedule
      • Morning lectures (except tour and extra labs)
      • Afternoons in the lab
  4. Behavior
    • One person talking at a time
    • Raise hand or interrupt politely
    • Classroom - No:
      • Cellphones
      • Laptops
      • Texting
      • IMing
      • Etc.
    • Lab more casual, but distractions may slow you down
  5. Grades
    • 50% labs
    • 20% homework
    • 20% project
    • 10% participation
  6. Talk more about labs this afternoon
  7. Homework
    • 1-2 assignments per week
    • Math, physics, programming exercises
    • Background for labs (pre-labs)
  8. Please ask questions, we need open dialogue
  9. Any questions?

Motivation

  • Class has two goals:
    1. Learn what computers are used for in science
    2. Learn how to use them effectively for science
  • The first is the nominal basis for the class
    • Learn about data analysis, numerical methods, simulations, etc.
  • The second is based on my perception of need
    • If you study science or engineering you'll take classes on programming, math and physics, or biology...
    • ...but there are no courses on good software development techniques
  • So, in addition to showing you how to model the Solar System, you'll learn some useful skills
    • The kind of things you can use in a job
    • The kind of things that will make you really attractive as an undergraduate researcher
    • The kind of things that could help you do research for a long time
  • Think of this course as part fun and exciting, and part skill development for professionals

The State of Play

  • Computers are as important to scientists as telescopes and test tubes
    • Simulate things that are too big, too small, too fast, too slow, or too dangerous to study in the lab
    • Analyze volumes of data that would overwhelm human “computers”
  • Many scientists now spend much of their time writing and maintaining software
  • But most have never been taught how to do this efficiently
    • It's a long way from the loops and arrays of first year to simulating bone development in foetal marsupials
    • Like being shown how to differentiate polynomials, then expected to invent the rest of calculus
  • As a result, scientists spend far more time programming than they ought to
    • And they still don't know how trustworthy their programs are

Meeting Standards

  • Experimental results are only publishable if they are believed to be correct and reproducible
    • Equipment calibrated, samples uncontaminated, relevant steps recorded, etc.
  • In practice, rely on expectations and cultural norms
    • Drilled into people starting with their first high school chemistry class
    • Only actually check work that is already under suspicion
  • How well do computational scientists meet these standards?
    • Correctness of code rarely questioned
      • We all know programs are buggy…
      • ...but when was the last time you saw a paper rejected because of concerns over software quality?
    • Reproducibility often nonexistent
      • How many people can reproduce, much less trace, each computational result in their thesis?

The Grass Isn't That Much Greener

  • The bad news is that things aren't that much better in industry
    • Commercial projects of all sizes routinely go over time and over budget
    • What they deliver is often incomplete, riddled with bugs, and not what the customer actually wanted
  • How is this possible?
    • Low expectations
      • Like American cars in the 1970s
    • Lack of accountability
      • Hard to sue software developers
      • Most shrink-wrap licenses effectively say, “This CD could be blank, and we wouldn't have to give you back your money.”

Hidden in Plain Sight

  • The good news is that we've had solutions for these problems for years
    • They just aren't evenly distributed
    • This is one of the reasons good programmers are up to 28 times better than bad ones [Glass 2002]
  • Improving quality improves productivity
    • The more effort you put into making sure it's right the first time, the less total time it'll take to get it built
  • The tools and techniques that help you write better code also help you write more code, faster
    • Version control
    • Test-driven development
    • Task automation
    • Symbolic debuggers
    • And more that we'll meet later

This Course

  • Introduce some basic tools
    • Instant gratification
    • Serve as a guide to good practice
      • Every software tool implicitly embodies someone's ideas about how a task should be done
  • Show how to build tools like these
    • What goes into the software
    • How to create it
    • Don't expect you to write your own version control system or bug tracker
      • But do expect you to automate common tasks, make your products extensible, etc.
  • Show how to apply these ideas to other tasks
    • Most modern well-engineered applications are implemented as specialized sets of tools
    • (Where “well-engineered” means flexible, reliable, and maintainable)
  • Keep in mind that it's impossible to cram an undergraduate degree and several years of industry experience into one course
    • If you really want to improve, you have to treat this course as a starter's block, not a finishing line