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.

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/79157069@N03/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