Maintaining Software Correctness
Dan Lew
source: https://www.
fl
ickr.com/photos/eliasroviello/43464129670
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
RxLifecycle
observable
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.bindToLifecycle() // Forget this and leak memory!
.subscribe()
Slide 4
Slide 4 text
RxLifecycle
observable
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.bindToLifecycle() // Forget this and leak memory!
.subscribe()
Slide 5
Slide 5 text
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
Slide 6
Slide 6 text
design for human fa libility
l
Slide 7
Slide 7 text
Two Big Ideas
• Human processes can become software processes
• The less freedom you give, the more likely you’ll maintain correctness
Institutional Knowledge
• Stu
ff
in your head
• The good
• Everything starts here
• Cheap
• Flexible
• Explains & summarizes
• Describes human problems
Slide 12
Slide 12 text
Institutional Knowledge
• The bad
• Misremembered, forgotten, or leaves
• Laborious to share
• Hard to communicate
• No reminders
Software Checks
• Code that checks itself
• Timing matters!
• Fast feedback is better
Slide 27
Slide 27 text
Runtime Checks
• Checks while running your code
• Can check almost anything…
• …But, users might be your testers, oops!
• Use as last resort
Slide 28
Slide 28 text
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
Slide 29
Slide 29 text
Automatic Checks
• Manual tests that start themselves
Slide 30
Slide 30 text
Compiler Checks
• Compiler enforces its own rules
• Can go beyond the compiler…
• Code style
• Lint
• Code coverage
• Manual checks
Slide 31
Slide 31 text
Design Checks
• Checks editor makes before compilation
• Instant feedback
• Still not limited to compiler
• IDEs can support code style, lint, etc.
Slide 32
Slide 32 text
Software Checks
• Faster feedback is better
• Faster feedback is more constrained
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!
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
Analysis
• Consider correctness while solving problems
• Mix multiple strategies together
Slide 42
Slide 42 text
Analysis
• Rigidity gets you correctness…
• …but it costs you in
fl
exibility
• Balance
fl
exibility vs. correctness
Slide 43
Slide 43 text
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
Slide 44
Slide 44 text
Analysis
• Need team buy-in
• Agreement makes correctness easier to implement
• Disagreement leads to toxicity
• Start with experiments, then make your case
Slide 45
Slide 45 text
source: https://www.picpedia.org/suspension-
fi
le/e/examples.html