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

Maintaining Software Correctness

Maintaining Software Correctness

Talk given at MinneBar 16 - https://www.youtube.com/watch?v=QHAD-BSG9Jo

----------

Suppose you’ve just designed a new architecture, library, or process. At first, everything’s going great, but over time you notice some issues - issues that stem from people that aren’t using your creation properly! If they’d just use everything correctly, there wouldn’t be any problems, but to your horror people continue to make mistakes and cause your beautiful product to fail.

People will always make mistakes, but the core mistake here is designing without keeping human fallibility in mind. It’s easy to come up with a new architecture, library, or process. But how do you make sure people use it correctly in the long run? Without considering this problem, your software will come up short.

In this talk, I’ll go over the task of maintaining software correctness, along with plenty of examples. By the end of this talk, you’ll have a bunch of strategies for writing software that encourages correct implementations in the long run.

Daniel Lew

June 04, 2022
Tweet

More Decks by Daniel Lew

Other Decks in Programming

Transcript

  1. Maintaining Software Correctness
    Dan Lew
    source: https://www.
    fl
    ickr.com/photos/eliasroviello/43464129670

    View Slide

  2. View Slide

  3. RxLifecycle
    observable
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .bindToLifecycle() // Forget this and leak memory!
    .subscribe()

    View Slide

  4. RxLifecycle
    observable
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .bindToLifecycle() // Forget this and leak memory!
    .subscribe()

    View Slide

  5. Correctness Dilemma
    • Stu
    ff
    is easy to create, hard to maintain!

    • Avoiding RxJava memory leaks

    • Maintaining code style

    • Contributing to an OSS codebase

    • Consistently releasing builds

    View Slide

  6. design for human fa libility
    l

    View Slide

  7. Two Big Ideas
    • Human processes can become software processes

    • The less freedom you give, the more likely you’ll maintain correctness

    View Slide

  8. Correctness Strategies
    source: https://pixabay.com/photos/target-aim-arrows-bow-quiver-459833/

    View Slide

  9. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  10. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  11. Institutional Knowledge
    • Stu
    ff
    in your head

    • The good

    • Everything starts here

    • Cheap

    • Flexible

    • Explains & summarizes

    • Describes human problems

    View Slide

  12. Institutional Knowledge
    • The bad

    • Misremembered, forgotten, or leaves

    • Laborious to share

    • Hard to communicate

    • No reminders

    View Slide

  13. Institutional Knowledge

    View Slide

  14. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  15. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  16. Documentation
    • Institutional knowledge, written down

    • Harder to forget

    • Easier to broadcast

    • Can use visuals

    • Checklists for complex processes

    View Slide

  17. Documentation
    • The bad…

    • Badly written or misunderstood

    • Often poorly maintained

    • Hard to
    fi
    nd or just ignored

    • No reminders

    View Slide

  18. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  19. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  20. Affordances
    “The quality or property of
    an object that de
    fi
    nes its
    possible uses or makes
    clear how it can or should
    be used”

    View Slide

  21. Affordances
    https://commons.wikimedia.org/wiki/File:Set_of_Crash_Bar_Doors.jpg
    VS
    https://www.
    fl
    ickr.com/photos/[email protected]/40530223463

    View Slide

  22. Affordances
    • A
    ff
    ordant APIs invisibly guide people toward correctness

    • Una
    ff
    ordant APIs make exceptions uncomfortable

    • Existing code creates peer pressure

    • A
    ff
    ordances cannot restrict, only guide

    View Slide

  23. Affordances

    View Slide

  24. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  25. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  26. Software Checks
    • Code that checks itself

    • Timing matters!

    • Fast feedback is better

    View Slide

  27. Runtime Checks
    • Checks while running your code

    • Can check almost anything…

    • …But, users might be your testers, oops!

    • Use as last resort

    View Slide

  28. Manual Checks
    • Unit/integration/etc. tests

    • Very wide range of testable logic!

    • Must foster culture of testing

    • Architecting for tests

    • Taking time to write tests

    • Verifying test correctness

    View Slide

  29. Automatic Checks
    • Manual tests that start themselves

    View Slide

  30. Compiler Checks
    • Compiler enforces its own rules

    • Can go beyond the compiler…

    • Code style

    • Lint

    • Code coverage

    • Manual checks

    View Slide

  31. Design Checks
    • Checks editor makes before compilation

    • Instant feedback

    • Still not limited to compiler

    • IDEs can support code style, lint, etc.

    View Slide

  32. Software Checks
    • Faster feedback is better

    • Faster feedback is more constrained

    View Slide

  33. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  34. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  35. Constraints
    • Make it impossible to do wrong

    • Enums vs. stringly-typing

    • Stateless functions vs. stateful classes

    • Pull requests vs. merging to main

    • Bonus: limits headspace & test cases, too!

    View Slide

  36. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  37. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  38. Automation
    • No humans are involved

    • Code generation

    • Continuous integration

    • Automatic deployments

    • Write once, run over and over

    • High e
    ff
    ort to write & maintain automation

    View Slide

  39. Correctness Strategies
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  40. Analysis
    source: https://pxhere.com/en/photo/1450669

    View Slide

  41. Analysis
    • Consider correctness while solving problems

    • Mix multiple strategies together

    View Slide

  42. Analysis
    • Rigidity gets you correctness…

    • …but it costs you in
    fl
    exibility

    • Balance
    fl
    exibility vs. correctness

    View Slide

  43. Analysis
    • You can implement correctness badly

    • Flakey software checks

    • Annoying contribution process

    • Di
    ffi
    cult automation maintenance

    • No escape hatch for new features

    • Make sure costs are worth it

    View Slide

  44. Analysis
    • Need team buy-in

    • Agreement makes correctness easier to implement

    • Disagreement leads to toxicity

    • Start with experiments, then make your case

    View Slide

  45. source: https://www.picpedia.org/suspension-
    fi
    le/e/examples.html

    View Slide

  46. Code Style
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  47. Contributing to an OSS project
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  48. Cleaning Streams
    • Institutional Knowledge

    • Documentation

    • A
    ff
    ordances

    • Software Checks

    • Constraints

    • Automation
    Flexible
    Rigid

    View Slide

  49. @danlew42

    View Slide