Introduction

Lecture Notes for CS 190
Spring 2015
John Ousterhout

Course Motivation

  • The most important overall idea in CS: problem decomposition.
    • How to take a large, complex system and decompose it into relatively independent pieces
    • Not really taught in any classes
  • Huge difference in productivity between average programmers and the best programmers
    • 10-100x
    • What are the skills that distinguish elite programmers?
    • Can these skills be taught?

Complexity

  • Biggest limitation in building large software systems is complexity
    • Interdependencies: behavior in one part of system affects behavior elsewhere
    • To understand how one piece of code works, must understand many other pieces
  • Complexity increases as system ages
    • Code becomes more and more intertwined
  • Complexity makes it hard to add features, fix bugs:
    • Can't understand current behavior
    • Can't predict the implications of a change
    • Eventually, can't fix one bug without introducing another; expensive to add new features that work
  • Why is it hard to make changes to a system?
    • May have to modify many lines of code
    • May have to understand many lines of code
    • Can't determine which lines to understand or modify
  • Changes are easier to make if you can keep all of the code for the system in your mind at once
  • How much code can you keep in your mind?
    • Most developers: a few hundred to a few thousand lines
    • Best possible case (rumors): 50,000 lines?
  • Today's large software systems: tens of millions of lines
  • Most important element in software design: minimize complexity
    • Makes improvements cheaper, faster
    • Allows more functionality before system becomes unmaintainable

Minimizing Complexity

  • Modularity
  • Abstraction
  • This class is about how to design software in order to minimize complexity

Course Structure

  • Iteration
    • Create a nontrivial application from scratch
    • Give and receive criticism
    • Rewrite to fix the problems
  • Criticism:
    • I will read all projects
    • You will read each other's projects
    • In-class code reviews
  • Goal for course: beautiful code
    • Clean, simple, obvious
    • Correctness less important (within reason)
  • The project: Twitter-like Web service
    • Work in teams of 2
    • Code in Java
    • Phase 1: build basic server
    • Phase 2: revise based on code reviews
    • Phase 3: take someone else's project, add new functionality, refactor existing structure
  • Class format:
    • 1/3 lectures (50 minutes)
    • 1/3 code reviews (50-75 minutes)
    • 1/3 cancelled to make time for programming
    • Special discussions, group designs, etc.?
    • Class attendance is mandatory
    • Grading policy:
      • No exams
      • Grades based on project work and class participation
    • Late days
    • Office hours
    • Piazza for communication
    • Workload is front-end loaded
  • Class participation is important
  • Giving and receiving criticism is very important
    • Expect to receive lots of feedback, may be intense:
      • Unlikely that any of you is already a good programmer
      • Small details matter
    • Keep criticism constructive:
      • It's about the code, not the person
      • Remember that everyone is learning
  • Need your feedback to improve the class (I'm learning also)
  • Realistic expectations
    • Can't become an elite programmer in 10 weeks
    • Goal: teach you concepts that you can apply and refine over 5-10 years to become an elite programmer
    • Red flags: things that tell you you are doing something wrong
    • This class won't cover everything you need to know
  • Most important overall idea for the class: deciding what is important
  • Get started right away!