Executive Summary

• The three core ideas of Tiger Style:
  • See the whole picture. (always think about design, coding, testing, operator experience)
  • Check yourself before you wreck yourself. (assertions)
  • Give yourself a time machine. (simulation)
• Developing is system is more than just coding.
  • Design
  • Coding
  • Testing
  • Operator experience in Production
• Don't be hasty. An hour in design is worth weeks in production.
• Testing is what dominates the development of complex systems.
• How you paint your software from scratch is all about 4 colors and 2 textures:
  • Network, Disk, Memory and CPU
  • Latency and Bandwidth
• Use assertions everywhere!
  • The slightest logic bugs should shut everything down.
• Limit your loops with minumum and maximum bound assertions
  • Everything has a limit and you must make the limits explicit.
• Design for simulation from day 1
  • Simulation lets you test in days what you'd take years to find in the real world.

The video

Notes on the video

• (Pg 4:59) "Tigerstyle sees the whole picture, checks yourself before you wreck yourself, gives you a time-machine!"
• (Pg 6:25) "Decide your tools on quality, not quantity" [tools]
• (Pg 7:25) "Developing a system is not just about coding … the design phase before and after, the coding, the testing phase after coding and the operator experience in production" [coding]
• (Pg 7:55) "Total time of ownership = Design + Coding + Testing + Incidents" [shipping]
• (Pg 10:10) "An hour in design is worth weeks in production" [quotes]
  • by Joran Dirk Greef
• (Pg 10:40) "Simple and Elegant Systems tend to be easier and faster to design and get right, more efficient in execution and much more reliable" [quotes]
  • by Edsger Dijkstra
• (Pg 13:10) "Testing is what dominates the development of complex systems." [testing]
• (Pg 13:15) "Callout to Jepsen as a great tool for testing distributed systems!" [jepsen, clojure]
• (Pg 15:25) "There is more to software than just engineering. It is at least the intersection of engineering and art." [building]
• (Pg 18:40) "Four colors of systems programming: Network, Disk, Memory, CPU" [distributedsystems]
• (Pg 18:56) "The two textures that all these colors share are: latency and bandwidth" [distributedsystems]
• (Pg 19:10) "In the design phase … 1) Back of the envelope calculations" [design]
• (Pg 19:30) "Sketch as many solutions as you can using … (colors, textures) .. because sketches are cheap and rewrites are expensive" [design]
• (Pg 19:40) "Find great names for your components … TigerStyle doc in our repo gives you tips on naming" [design]
• (Pg 20:35) "Define your mechanical fault models" [design]
  • Think through your fault models and see if your system is designed accordingly.
• (Pg 21:10) "Be explicit up front about the fault models your system can tolerate" [design]
• (Pg 21:40) "Stateless is always better than stateful" [design,state]
  • State is very hard! :D
• (Pg 22:00) "It pays to reduce surface area that you commit to. The more surface area, the more unexpected interactions." [design]
• (Pg 23:00) "Zero Technical Debt policy … do the best that you currently can … do it right the first time" [design]
  • Knowing that your work is solid motivates your team
• (Pg 24:00) "Walk and Talk when you are discussing hard problems" [design]
  • Walking and discussing is really simulating for the brain.
  • Design tricks put you in good place for coding.
• (Pg 26:30) "Assertions: NASA's power of ten rules for safety critical code" [reference]
  • Your system should run safely or not at all .. shut down in the face of a bug.
• (Pg 27:30) "Write assertions checking your function arguments" [correctness]
  • that they are as you expect, and also assert that they are correct in relation to each other.
  • and you do the same for the return value
  • now your functions are contributing to correctness
• (Pg 27:42) "The ultimate purpose of abstraction is for correctness" [quotes]
  • By Joran
• (Pg 29:00) "If it compiles, you've just begun!" [correctness]
• (Pg 30:20) "Start to think like a hacker: what don't you expect? What would be unusual in this case?" [hackers]
• (Pg 32:40) "Everything has a limit … systems have limits .. make them explicit so that your design can handle edge-cases" [limits, distributedsystems]
• (Pg 34:09) "Static memory allocation is just one example of everything having a limit." [limits]
  • Memory, Network, CPU, Disk all have limits and need to apply back-pressure.
• (Pg 36:10) "Assertions are a force-multiplier for testing" [testing]
  • Do not let your programming language turn them off in production!
• (Pg 45:30) "Assertions document invariants" [testing]
  • Now people can see the positive space (your logic) as well as the negative space (what shouldn't happen)
  • That is what teachers do, they want to teach you the right way and also the wrong way.
• (Pg 47:30) "(our fuzzy simulator) .. push the faults to the very theoretical limit .. at rapid time" [fuzzying, testing, distributedsystems]

Published On: Mon, 26 Jun 2023. Last Updated On: Sun, 04 Aug 2024.