Lessons from Zero-Defect Software

30-minute Talk - date TBD at time TBD in room TBD

Writing software with no defects is extremely difficult and expensive, but the lessons learned from such ambitious projects can inform our approach for a more practical development technique. This talk looks at how principles from zero-defect engineering, functional programming, and refactoring come together to produce robust, readable, and reliable code.

  1. Introduction
    1. My background
      1. computer science
      2. scheme (functional)
      3. zero-defect software
    2. Passion for reliability, re-use, sophistication
    3. Introspect how to come to elegant techniques
      1. Not all my techniques are elegant
      2. It's a joy when they are
    4. Try to distill some examples from elegant code to principles that led to them.
      1. Refactoring
      2. Functional programming
      3. Zero-defect software
    5. What about testing? This talk avoids talking about tests, which are still practical and necessary, but aims to build reliable code without relying on tests
  2. Refactoring
    1. From Martin Fowler's book of the same title.
      1. The one book that made me a better programmer more than any other.
    2. Rely on implementation as the spec (assuming correct, restructure without altering semantic meaning)
    3. DRY - factor the code such that the code does what it's intended to and not more
    4. Use automated tools
      1. PyCharm
      2. Or don't, but follow the principles: commit between refactoring steps, even if you squash later (but please don't)
    5. Reshape the code to match the conceptual needs
    6. Keep functions small (fit on the screen might fit in your mind)
    7. Examples
      1. Extract function/method
      2. init/for/append -> single assignment
  3. Functional Programming
    1. What is the functional programming paradigm?
      1. Not what you were taught (set of instructions)
    2. Why is it beneficial?
      1. Stateless; no side effects
      2. Focus on what machines do best - perform an operation over a number of inputs
      3. Simple concepts are more scalable (map/reduce forms foundation of Hadoop)
    3. Compare for loop to list comprehension
    4. Limit parameters of functions (one input, one output ideal)
    5. Avoid boolean parameters (small change doubles states)
      1. Consider separate functions
    6. Examples:
      1. map
      2. reduce
      3. compose
  4. Zero-defect Software
    1. Levels of rigor
      1. Mathematically-provable code
        1. brute-force all possible inputs
      2. Verifiably correct code
      3. Code written for verifiability
    2. Only the most simple code is mathematically provable; only simple code is verifable.
      1. Compose more complex functionality from verifiably-correct components.
      2. Limit the surface of the components.
      3. OO programming can help here to encapsulate state
    3. Use refactoring and functional programming principles to simplify the code safely
    4. Avoid if statements or other branching logic (number of states the sub program can be in)
      1. Think of 'if' statements like gotos. Avoid them - there's probably a better way
    5. Examples and case studies
      1. Examine a number of case studies drawn from real-world commits
  5. Conclusion
    1. What is the common factor of all of this?
    2. Reducing interactions
    3. Reduces complexity
    4. Elegance begets simplicity
    5. Python is particularly well-suited to adopt functional, OO, or imperative paradigms when appropriate

Presented by: