TigerStyle, or how to design safer systems in less time by Joran Dirk Greef

Meta information

Executive Summary

I'll write the executive summary – my takeaways from the talk – when I see the talk a second (or maybe third) time. Nothing to add for the moment.

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" [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." [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 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 36:10) "Assertions are a force-multiplier for testing" [testing]
    • Do not let your programming language turn them off in production!
  • (Pg 45:50) "Assertions document invariants" [testing]
  • (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: Tue, 14 May 2024.