Fighting Complexity in Elixir

This talk discusses how several ideas from John Ousterhout's book "A Philosophy of Software Design" can be applied to Elixir code.

Transcript

1. Fighting
   Complexity
   

   View Slide

2. Software has almost no constraints.
   

   View Slide

3. Software has almost no constraints.
   We can make pigs fly, if we want to.
   

   View Slide

4. If you can imagine a system, you can probably
   build it in software.
   

   View Slide

5. The greatest limitation in software is our ability to understand
   the systems we are creating.
   — John Ousterhout, A Philosophy of Software Design
   

   View Slide

6. As we add new features, our code evolves and naturally
   becomes more complicated.
   Subtle dependencies emerge.
   

   View Slide

7. Over time, this complexity accumulates.
   

   View Slide

8. It becomes harder and harder for us to keep all of the
   relevant information in our minds …
   Over time, this complexity accumulates.
   

   View Slide

9. Because the system is becoming complex and we’re struggling
   to keep all the details in our minds:
   

   View Slide

10. Because the system is becoming complex and we’re struggling
    to keep all the details in our minds:
    It becomes harder to add new features … it slows us down.
    

    View Slide

11. Because the system is becoming complex and we’re struggling
    to keep all the details in our minds:
    We can easily miss some detail and create bugs …
    which further slows us down.
    It becomes harder to add new features … it slows us down.
    

    View Slide

12. The effect multiplies and accelerates with every new
    contributor to our codebase.
    

    View Slide

13. Progress starts to stagnate and costs start to grow rapidly.
    

    View Slide

14. Fighting
    Complexity
    Its all about:
    

    View Slide

15. Stamina
    Simpler, less complex, designs allow us to build larger more
    powerful systems before complexity becomes overwhelming.
    Its about building:
    

    View Slide

16. Complexity
    Anything related to the structure of a codebase that makes it hard to
    understand or improve that codebase.
    

    View Slide

17. Change Amplification
    Symptom 1:
    A seemingly simple change requires code
    modification in many places.
    

    View Slide

18. Cognitive Load
    Symptom 2:
    How much information does a developer need to
    make a change to the system.
    

    View Slide

19. Unknown unknowns
    Symptom 3:
    It’s not obvious which pieces of code must be modified to complete
    a task, or what information a developer must have to carry out the
    task successfully.
    

    View Slide

20. Complexity is caused by two things
    dependencies and obscurity.
    

    View Slide

21. Tactical Programming
    In the tactical approach, our main focus is to get something
    working. This is how systems become complicated - one small
    compromise at a time.
    

    View Slide

22. Strategic Programming
    The first step towards becoming a good software designer is to realize that working code isn’t
    enough. It’s not acceptable to introduce unnecessary complexities in order to finish your
    current task faster.
    The most important thing is the long-term structure of the system. Our primary goal must be to
    produce a great design, which also happens to work. This is strategic programming.
    – John Ousterhout. A Philosophy of Software Design
    

    View Slide

23. View Slide

24. The Tactical Tornado
    

    View Slide

25. View Slide

26. The simple parts of reducing
    Cognitive Load …
    Good names, good comments, consistency, mix format, credo etc.
    

    View Slide

27. Modular Design
    A developers only need to face a small fraction of the overall
    complexity at any given time.
    

    View Slide

28. Does not mean more modules.
    

    View Slide

29. Encapsulation
    Encapsulate complexity so our team can work on other parts
    of the system without being exposed to the complexity
    encapsulated in this module.
    

    View Slide

30. In Elixir we can encapsulate at the function
    level and at the module level.
    

    View Slide

31. Deep Modules
    The best modules are those that provide powerful
    functionality yet have simple interfaces.
    

    View Slide

32. View Slide

33. View Slide

34. View Slide

35. With a sufficient number of users of an API, it does not matter
    what you promise in the contract: all observable behaviours of
    your system will be depended on by somebody.
    Hyrum's Law:
    Use defp.
    

    View Slide

36. Loose Coupling
    Components in a loosely coupled system can be replaced with
    alternative implementations that provide the same services.
    

    View Slide

37. Polymorphism
    The ability to present the same interface for differing underlying forms
    

    View Slide

38. Messages
    Processes can send messages to other processes without
    needing to care what the receiver process is or does.
    The interface is Process IDs and Kernel.send/2
    

    View Slide

39. Behaviors
    A module that defines a spec which other modules can
    implement.
    

    View Slide

40. View Slide

41. Protocols
    A group of function headers that a data type must implement if it
    is considered to be implementing that protocol.
    

    View Slide

42. View Slide

43. View Slide

44. Functions
    

    View Slide

45. View Slide

46. Dependency Inversion
    High-level modules should not depend on low-level modules.
    Both should depend on abstractions (e.g. interfaces).
    Abstractions should not depend on details.
    Details (concrete implementations) should depend on abstractions..
    

    View Slide

47. github.com/ockam-network/ockam
    

    View Slide

48. View Slide

49. github.com/ockam-network/ockam
    Mrinal Wadhwa
    twitter.com/mrinal
    CTO @ Ockam
    

    View Slide