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
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