Slide 1
Slide 1 text
Chris Krycho – LambdaConf 2024
Resiliency, Limits, & Moral Hazards
in Software Engineering
Seeing Like a Programmer
Slide 2
Slide 2 text
A little bit about me
Hello!
• 15 years in software
engineering
• Aircraft software
• Energy industry safety
• Restaurant ordering
• Deve
l
oper too
l
s and web
frameworks at LinkedIn
Slide 3
Slide 3 text
How do we make
good software?
Slide 4
Slide 4 text
Engineering
Modernity and intellectual modernism
Humility
Slide 5
Slide 5 text
What is software?
Slide 6
Slide 6 text
“[It] is important to have an appropriate understanding
of what programming is. If our understanding is
inappropriate we will misunderstand the di
ffi
culties
that arise in the activity and our attempts to overcome
them will give rise to con
fl
icts and frustrations.
—Peter Naur, “Programming as Theory Building”, 1985
Slide 7
Slide 7 text
Software is artifact and system.
Slide 8
Slide 8 text
Software as artifact
Slide 9
Slide 9 text
“The score is potential ener
gy
. It’s the potential for
music to happen, but it’s not the music.
—Eímear Noone, composer and conductor
Slide 10
Slide 10 text
Software as system
Slide 11
Slide 11 text
Software is artifact and system.
Slide 12
Slide 12 text
Good software artifacts
Slide 13
Slide 13 text
What do we know?
Good software artifacts
• Domain-driven design
• “Make I
l
l
ega
l
States Unrepresentab
l
e”
Slide 14
Slide 14 text
“Make Illegal States Unrepresentable”
Good software artifacts
struct RequestData {
is_loading: bool,
is_loaded: bool,
is_error: bool,
value: Option,
error: Option,
}
let data = RequestData {
is_loading: true,
is_loaded: false,
is_error: true,
value: Some("oh no"),
error: None,
};
Slide 15
Slide 15 text
“Make Illegal States Unrepresentable”
Good software artifacts
enum RequestData {
Loading,
Loaded(Value),
Error(String),
}
let data = RequestData
::
Loaded("Phew");
Slide 16
Slide 16 text
What do we know?
Good software artifacts
• Domain-driven design
• “Make I
l
l
ega
l
States Unrepresentab
l
e”
• Proofs and forma
l
veri
fi
cation
• Forma
l
mode
l
ing
• Testing: regression tests, test-driven design (TDD), property-based
testing, performance testing
Slide 17
Slide 17 text
Good software systems
Slide 18
Slide 18 text
—Donella Meadows, Thinking in Systems
“Systems happen all at once. They are connected not
just in one direction, but in many directions
simultaneously.
Slide 19
Slide 19 text
—Donella Meadows, Thinking in Systems
“Resilience is not the same thing as being static or
constant over time. Resilient systems can be very
dynamic. Short-term oscillations, or periodic
outbreaks, or long cycles of succession, climax, and
collapse may in fact be the normal condition, which
resilience acts to restore!
And, conversely, systems that are constant over time
can be unresilient.
Slide 20
Slide 20 text
What do we know?
Good software systems
• Let it crash (Er
l
ang)
• Hand
l
e crashiness we
l
l
Slide 21
Slide 21 text
—Keunwoo Lee, “On Rebooting”
“Your beautiful crash-only error handling strate
gy
has
nudged your system into a new equilibrium where the
backend is continually receiving too much load. A
local defect has been ampli
fi
ed into a global system
outage. Even if you remove the crashing defect, the
fl
ood of retrying startup queries may persist as a
metastable failure mode of your system.
Slide 22
Slide 22 text
What do we know?
Good software systems
• Let it crash (Er
l
ang)
• Hand
l
e crashiness we
l
l
• Observabi
l
ity (visibi
l
ity): tracing and monitoring
Slide 23
Slide 23 text
Programming as
Theory-Building
Slide 24
Slide 24 text
What state transitions are legal here?
Programming as Theory-Building
enum RequestData {
Loading,
Loaded(Value),
Error(String),
}
Slide 25
Slide 25 text
Why this representation and not another?
Slide 26
Slide 26 text
—Peter Naur, “Programming as Theory-Building”, 1985
“…the theory built by the programmers has primacy
over such other products as program texts, user
documentation, and additional documentation such
as speci
fi
cations… in at least three essential areas:
Slide 27
Slide 27 text
—Peter Naur, “Programming as Theory-Building”, 1985
1. The programmer… can explain how the solution
relates to the a
ff
airs of the world that it helps to
handle.…
2. The programmer… can explain why each part of the
program is what it is, in other words is able to support
the actual program text with a justi
fi
cation of some
sort.…
3. The programmer…is able to respond constructively
to any demand for a modi
fi
cation of the program so
as to support the a
ff
airs of the world in a new manner.
Slide 28
Slide 28 text
—Peter Naur, “Programming as Theory-Building”, 1985
“In several major cases it turned out that the solutions
suggested by group B [(not the original authors)] were
found by group A [(the original authors)] to make no
use of the facilities that were not only inherent in the
structure of the existing [program] but were discussed
at length in its documentation.
Slide 29
Slide 29 text
“Legacy code” is code for which
we do not have a mental model—
a theory.
Slide 30
Slide 30 text
The model—the theory—
lives in our minds.
Slide 31
Slide 31 text
Decisions
Slide 32
Slide 32 text
Heuristics and aphorisms
Decisions
“Prefer duplication to the wrong abstraction.
—Sandi Metz
—approximately everyone
“Don’t repeat yourself.
Slide 33
Slide 33 text
—Peter Naur, “Programming as Theory-Building”, 1985
“ …if the exercise of intelligence depended on following
rules there would have to be rules about how to follow
rules, and about how to follow the rules about
following rules, etc. in an in
fi
nite regress, which is
absurd.
Slide 34
Slide 34 text
—James C. Scott, Seeing Like a State, p. 313
“…a wide array of practical skills and acquired
intelligence in responding to a constantly changing
natural and human environment.
Mētis
Slide 35
Slide 35 text
Legibility
Slide 36
Slide 36 text
…for our own systems!
Legibility
enum RequestData {
Loading,
Loaded(Value),
Error(String),
}
Slide 37
Slide 37 text
Two paths
Legibility
1. Embrace the fact that
l
egibi
l
ity is
l
imited.
2. Reshape the wor
l
d to be more
l
egib
l
e.
Slide 38
Slide 38 text
High modernism
Slide 39
Slide 39 text
—James C. Scott, Seeing Like a State, p. 4
“…a strong… version of the self-con
fi
dence about… the
mastery of nature (including human nature), and,
above all, the rational design of social order…
Slide 40
Slide 40 text
—Donella Meadows, Thinking in Systems
“People who are raised in the industrial world and who get
enthused about systems thinking are likely to make a terrible
mistake.… to assume that here, in systems analysis, in
interconnection and complication… is the key to prediction
and control.… because the mind-set of the industrial world
assumes that there is a key to prediction and control.
Slide 41
Slide 41 text
—James C. Scott, Seeing like a State, p. 262
“The necessarily simple abstractions of large
bureaucratic institutions… can never adequately
represent the actual complexity of natural or social
processes. The categories that they employ are too
coarse, too static, and too stylized to do justice to the
world that they purport to describe.
Slide 42
Slide 42 text
This is lossy compression.
Software and modernism
enum RequestData {
Loading,
Loaded(Value),
Error(String),
}
Slide 43
Slide 43 text
—John Salvatier
“Reality has a surprising amount of detail.
Slide 44
Slide 44 text
Humility
Slide 45
Slide 45 text
—Levi Wall
“Disruptive logic often requires an oversimpli
fi
cation of
a perceived problem..
Slide 46
Slide 46 text
Is this software good?
Slide 47
Slide 47 text
Ambition
Slide 48
Slide 48 text
—Peter Naur, “Programming as Theory-Building”
“In including
fl
exibility in a program we build into the program
certain operational facilities that are not immediately
demanded, but which are likely to turn out to be useful. Thus a
fl
exible program is able to handle certain classes of changes of
external circumstances without being modi
fi
ed.… However,
fl
exibility can in general only be achieved at a substantial cost.
Slide 49
Slide 49 text
To make good software.
Robust and resi
l
ient.
Respect the surprising amount of detai
l
in rea
l
ity.
Reinforce mētis.
Enab
l
e and empower and e
l
evates peop
l
e.
Ambition
Slide 50
Slide 50 text
Rigor
Perseverance
Imagination
Slide 51
Slide 51 text
I appreciate your attention.
Thank you!
• Fo
l
l
ow me: chriskrycho.com
• Emai
l
me: he
l
l
[email protected]
• Hire me!
• front-end technica
l
strategy
• TS adoption & conversion
• Rust workshops
• hard prob
l
em ana
l
ysis
• bui
l
ding “ratchets” to improve
software qua
l
ity
51