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.