Introduction

Lecture Notes for CS 190
Winter 2018
John Ousterhout

Complexity

  • Biggest limitation in building large software systems is complexity
  • No-one can fully understand a large software system: can't keep it all in your mind at once
  • Can't predict the implications of a change
  • Expensive to add features, fix bugs (mistakes, undesired outcomes)
  • Fixing one problem introduces another
  • Complexity increases as system ages
  • This class is about designing software to manage complexity
    • Eliminate complexity
    • Hide complexity: modular design
      • Decompose large system into pieces that are mostly independent
      • Each module is relatively small
      • Most coding tasks involve only a few modules
      • Allows more functionality before system becomes unmaintainable
  • Software design is a continuous process: different from other kinds of engineering
    • Most engineering areas: design is only done at the beginning of a project
    • Early days of software: waterfall model: requirements definition, design, coding, testing, maintenance.
    • Problem: can't visualize a large software system well enough to design it all in advance
    • Approaches today tend to be more incremental (e.g. agile development):
      • Design a bit
      • Implement and evaluate
      • Refactor to fix problems
      • Design a bit more, and repeat
    • What you learn in earlier phases prevents mistakes in later phases
    • Works for software because it software so malleable
    • Result: you should always be thinking about design (i.e. reducing complexity)
  • Before CS 190, we didn't teach software design (nobody else does, either)

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: minimize apparent complexity
    • Clean, simple, obvious
    • Correctness less important (within reason)
  • Three phases for class:
    • Phases 1 and 2: Raft protocol for distributed consensus
      • Work in teams of 2
      • Code in Java
    • Phase 1: implement leader election mechanism
    • Phase 2:
      • Revise, based on code reviews
      • Add log mechanism, implement replicated shell
    • Phase 3: implement a regular expression parser
      • Very different design problem from Raft
    • Workload will be highest for Project 1
  • Class format:
    • Lectures (50 minutes)
    • Code reviews, other in-class activities (75 minutes)
    • Some classes cancelled to make time for programming
    • Class attendance is mandatory
    • Grading policy:
      • No exams
      • Grades based on project work and class participation
    • Late days
    • Office hours
    • Piazza for communication
    • Different rooms on MF and W
  • 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
    • Growth mindset
  • Need your feedback to improve the class (I'm learning also)
  • Overall goal for this class:
    • Change the way you think about programming
    • Learn principles that you can apply and refine over 5-10 years to become an elite programmer and designer
    • Red flags: indicators that you need to rethink your design.
    • Key skill: deciding what is important
  • Get started right away!
    • Pick partners immediately
    • Read Raft paper, Project 1 writeup, start designing/coding
    • Read software design book, Chapters 1-16.