Happened to watch John Ousterhout on “A philosophy of software design”. I found it good. John talked about good philosophies/patterns he observed while teching his students.

Here are my notes.

  • https://www.youtube.com/watch?v=bmSAYlu0NcY
  • No agreement on software design even though programming has been around for long time
  • Secrets of good software design
    • Working code isn’t enough - minimize complexity
    • Complexity comes from depedencies and obscurity
    • Strategic vs tactical programming - programming mindset
      • Tactical programming
        • Goal: get next feature out ASAP
        • Problem - hacks to make the future - difficult to work with it later - no design.
        • Most startups are tactical - “we can cleanup later”
      • Strategic programming
        • Goal: produce a gret design
        • simplify/invest for future development
          • How much to invest?
            • Make continual small improvement - 10-20% overhead
    • Classes should be deep
      • Minmal interface - implementation can be deep - deep class - good
      • complex interface - shallow implementation - shallow class - bad
      • Common wisdom - “classes and methods should be small” - bad
      • Length isn’t the big issue - abstraction is
      • How to manage complexity - executing common case should be easy
    • General-purpose classes are deeper
    • New layer, new abstraction
    • Comments should describe that are not obvious from code
    • define errors out of existence
      • Exceptions - huge source of complexity
      • common wisdom - “detect and throw as many as exceptions as possible”
      • better approach - Try minimise number of places to handle exceptions
        • Question - How do you inform clients type of errors if the number of exceptions are minimised? (wow! I thought about this question and someone in audience actually asked this)
          • It should be really easy to carry out common cases. You have to do testing to check all possible cases. When you try and build systems to keep people away from mistakes - you introduce lot of complexity.
      • When to throw exceptions? - When you cannot carry out your contract
      • Exceptions provide the value when they are thrown far.
    • Pull complexity downwards