17. Extreme Humility
wiki.c2.com/?ExtremeHumility
Ward Cunningham
I think Extreme Programming and several other similar
approaches are based on humility about our abilities:
● we won't be able to work out all the requirements up
front (so allow mid-course corrections).
18. Extreme Humility
wiki.c2.com/?ExtremeHumility
Ward Cunningham
● we won't get the design right first time. So don't try! Just
DoTheSimplestThingThatCouldPossiblyWork and then
RefactorMercilessly.
● we don't know how implementable this design is. So
implement it and see.
19. Extreme Humility
wiki.c2.com/?ExtremeHumility
Ward Cunningham
● we'll make mistakes in coding and interpreting designs.
So test everything, run the tests every time you make a
change.
● we don't understand the problem well enough to predict
what we'll need later. So YouArentGonnaNeedIt.
25. Manifesto for Software Craftsmanship
Raising the bar.
As aspiring Software Craftspeople
we are raising the bar of professional software development
by practicing it and helping others learn the craft.
2009
26. Not only working software,
but also well-crafted software
Not only responding to change,
but also steadily adding value
Not only individuals and interactions,
but also a community of professionals
Not only customer collaboration,
but also productive partnerships
Manifesto for Software Craftsmanship2009
31. Pair programming
● Respect
● ‘Let’s try your idea first’
● DRIVER: Thinking out loud
● NAVIGATOR: 10-second rule
● Don’t worry if it feels awkward at first
38. Place a rubber duck on your monitor
and describe your problems to it.
There's something magical about
stating your problems aloud
that makes the solution more clear.
Rubber Ducking
46. “Today a usual technique is
to make a program
and then to test it.“
47. The Humble Programmer - Dijkstra
(...)
Today a usual technique is to make a program and then to test it. But: program testing
can be a very effective way to show the presence of bugs, but is hopelessly inadequate
for showing their absence. The only effective way to raise the confidence level of a
program significantly is to give a convincing proof of its correctness. But one should
not first make the program and then prove its correctness, because then the
requirement of providing the proof would only increase the poor programmer’s
burden. On the contrary: the programmer should let correctness proof and program
grow hand in hand.
(...)
1972
53. “Write a test, make it run, make it right.
To make it run,
one is allowed to violate principles of good design.
Making it right means to refactor it.”
Dave Hoover
67. Code Kata: The GREETING KATA
/testdouble/contributing-tests/wiki/Greeting-Kata
/swkBerlin/kata-bootstraps
68. Retrospective
- Design decisions
- Inputs&Outputs vs User Stories
- Test names (intention/behaviour, no implementation)
- Too much logic in tests
- Actual vs Expected
87. “What we want is to work with
people that can make us better,
that are willing to share and learn from each other.
We do not want mere colleagues.
We want passionate and inspiring professionals
that we can call friends.”
93. Retrospective
- Design decisions
- Inputs&Outputs vs User Stories
- Test names (intention/behaviour, no implementation)
- Too much logic in tests
- Additional code for testing
94. Additional code for testing
- Equality Pollution
- JSON, XML, … readers
- Additional features