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

Maintaining Software Correctness

Maintaining Software Correctness

Talk given at MinneBar 16.

----------

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.

D225ebf0faa666ac7655cc7e4689283c?s=128

Daniel Lew
PRO

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

  2. None
  3. RxLifecycle observable .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .bindToLifecycle() // Forget this and leak

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

    memory! .subscribe()
  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
  6. design for human fa libility l

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

    • The less freedom you give, the more likely you’ll maintain correctness
  8. Correctness Strategies source: https://pixabay.com/photos/target-aim-arrows-bow-quiver-459833/

  9. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  10. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  11. Institutional Knowledge • Stu ff in your head • The

    good • Everything starts here • Cheap • Flexible • Explains & summarizes • Describes human problems
  12. Institutional Knowledge • The bad • Misremembered, forgotten, or leaves

    • Laborious to share • Hard to communicate • No reminders
  13. Institutional Knowledge

  14. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  15. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  16. Documentation • Institutional knowledge, written down • Harder to forget

    • Easier to broadcast • Can use visuals • Checklists for complex processes
  17. Documentation • The bad… • Badly written or misunderstood •

    Often poorly maintained • Hard to fi nd or just ignored • No reminders
  18. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  19. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  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”
  21. Affordances https://commons.wikimedia.org/wiki/File:Set_of_Crash_Bar_Doors.jpg VS https://www. fl ickr.com/photos/79157069@N03/40530223463

  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
  23. Affordances

  24. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  25. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  26. Software Checks • Code that checks itself • Timing matters!

    • Fast feedback is better
  27. Runtime Checks • Checks while running your code • Can

    check almost anything… • …But, users might be your testers, oops! • Use as last resort
  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
  29. Automatic Checks • Manual tests that start themselves

  30. Compiler Checks • Compiler enforces its own rules • Can

    go beyond the compiler… • Code style • Lint • Code coverage • Manual checks
  31. Design Checks • Checks editor makes before compilation • Instant

    feedback • Still not limited to compiler • IDEs can support code style, lint, etc.
  32. Software Checks • Faster feedback is better • Faster feedback

    is more constrained
  33. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  34. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  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!
  36. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  37. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  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
  39. Correctness Strategies • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  40. Analysis source: https://pxhere.com/en/photo/1450669

  41. Analysis • Consider correctness while solving problems • Mix multiple

    strategies together
  42. Analysis • Rigidity gets you correctness… • …but it costs

    you in fl exibility • Balance fl exibility vs. correctness
  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
  44. Analysis • Need team buy-in • Agreement makes correctness easier

    to implement • Disagreement leads to toxicity • Start with experiments, then make your case
  45. source: https://www.picpedia.org/suspension- fi le/e/examples.html

  46. Code Style • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  47. Contributing to an OSS project • Institutional Knowledge • Documentation

    • A ff ordances • Software Checks • Constraints • Automation Flexible Rigid
  48. Cleaning Streams • Institutional Knowledge • Documentation • A ff

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  49. @danlew42