Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Fighting Complexity in Elixir

Mrinal Wadhwa
September 19, 2020

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.

Mrinal Wadhwa

September 19, 2020
Tweet

More Decks by Mrinal Wadhwa

Other Decks in Programming

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