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. 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
  2. Two Big Ideas • Human processes can become software processes

    • The less freedom you give, the more likely you’ll maintain correctness
  3. Correctness Strategies • Institutional Knowledge • Documentation • A ff

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

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

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

    • Laborious to share • Hard to communicate • No reminders
  7. Correctness Strategies • Institutional Knowledge • Documentation • A ff

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

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

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

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

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

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

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

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  17. Runtime Checks • Checks while running your code • Can

    check almost anything… • …But, users might be your testers, oops! • Use as last resort
  18. 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
  19. Compiler Checks • Compiler enforces its own rules • Can

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

    feedback • Still not limited to compiler • IDEs can support code style, lint, etc.
  21. Correctness Strategies • Institutional Knowledge • Documentation • A ff

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

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

    ordances • Software Checks • Constraints • Automation Flexible Rigid
  28. Analysis • Rigidity gets you correctness… • …but it costs

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

    to implement • Disagreement leads to toxicity • Start with experiments, then make your case
  31. Code Style • Institutional Knowledge • Documentation • A ff

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

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

    ordances • Software Checks • Constraints • Automation Flexible Rigid