The document discusses concepts related to software craftsmanship including extreme programming, test-driven development, code katas, and pair programming. It summarizes Ward Cunningham's views on extreme humility in software development and emphasizes practices like continuous integration, evolutionary design, and not making decisions prematurely. The document also promotes raising the bar of professional software development through communities of practice and sharing knowledge to help others learn.

1. Talking about craftsmanship
with ‘ensaimadas’ and katas
Raquel M. Carmena
@codurance_ES
@scmallorca
@bberrycarmen

2. Thanks ...

3. THANKS ...
@ialbeniz

4. THANKS ...
@isacazorl

5. THANKS ...
@jllado

6. @brujula_talk @fdsaprogramacio
THANKS ...

7. THANKS ...
@codurance_ES

8. YOU
THANKS ...

10. Planning WELCOME & TALK
CODE KATA
TALK
CODE KATA
CLOSING

12. Once upon a time ...

14. 1992

15. 1998

16. 2003

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.

20. Extreme Humility
wiki.c2.com/?ExtremeHumility
Ward Cunningham
● we can't reliably write simple, understandable code on
our own, so we work in pairs for constant feedback.
In contrast, the (pure) WaterFall method is arrogant in its
confidence ...

21. Requirements
Analysis
Design
Coding
Testing
Lack of practice
Distance between master and apprentice
Difficulty in giving feedback
Don’t think
Lack of humility
Deployment
Separation

24. Requirements
Analysis
Design
Coding
Testing
Spikes
Master and apprentice
together
Everybody thinks
Humility
Deployment
Continuous integration,
deployment and delivery
Fast feedback
No separation
between coding
and quality
Evolutionary design
Postponed decisions

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

27. Practice ?

29. 1998

30. DRIVER NAVIGATOR

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

32. All the time?

33. DRIVER < > NAVIGATOR
● Ping-pong / Popcorn
● Chess clock

34. Recommendation

35. Idea

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

40. TDD do not ... make decisions for yourself

41. TDD is ... a guide

42. TDD is not ... a testing discipline

43. TDD is ... a design discipline

45. Let’s start from the beginning...

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

48. @KentBeck

49. PRODUCTION
CODE
TEST
CODE
Implementation

50. TEST
CODE
PRODUCTION
CODE
Behaviour/Intention

51. WRITE
TEST CODE
WRITE
PRODUCTION
CODE
REFACTOR

52. WRITE
TEST CODE
WRITE
PRODUCTION
CODE
REFACTOR
Humility

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

54. Refactor ?

55. Production code & Test code

56. 4 RULES OF SIMPLE DESIGN

57. “Design for the future.
Change is expensive.
Make it cheap by anticipating it.”

58. 4 RULES OF SIMPLE DESIGN
● Pass all the tests
● Reveal intention
● No duplication
● Fewer elements

59. 4 RULES OF SIMPLE DESIGN
● Pass all the tests
● Reveal intention
● No knowledge duplication
● Fewer elements

60. 4RSD
Clean architecture
C.R.P.
Connascence
S.o.C.
Cohesion
Coupling
P.O.L.A.
D.R.Y.
GoF Patterns
K.I.S.S.
Y.A.G.N.I.
Law of Demeter
S.O.L.I.D.
DDD
Screaming Architecture

61. Kata!

62. Rules

63. DRIVER NAVIGATOR

64. WRITE
TEST CODE
WRITE
PRODUCTION
CODE
REFACTOR
DRIVER <-> NAVIGATOR

65. WRITE
TEST CODE
WRITE
PRODUCTION
CODE
REFACTOR
$> git commit -m “RED: ... “
$> git commit -m “GREEN: ... “
$> git commit -m “REFACTOR: ... “

66. Arrange
Act
Assert

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

69. Actual vs Expected
assertThat(expected, is(actual))
assertThat(actual, is(expected))

70. A side benefit

74. A side benefit: coverage

75. Helping others ...

77. Writing ….

80. Not only reading ...

81. I love...
● About the author
● Preface
● Foreword
● Acknowledgements

86. Learning culture at your work
● Katas
● Lunch & Learn
● Book club
● ...

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

88. Kata !

89. Code Kata: SHOPPING CART KATA
/swkBerlin/kata-bootstraps

90. CRC Cards

91. CRC Cards
http://c2.com/doc/oopsla89/paper.html
A Laboratory For Teaching
Object-Oriented Thinking
Kent Beck, Apple Computer, Inc.
Ward Cunningham, Wyatt Software Services, Inc.

92. Growing Object-Oriented Software, Guided by Tests
Steve Freeman and Nat Pryce

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

96. To conclude...

104. @codurance_ES
@bberrycarmen