This talk happened at the University of Tarragona (URV) with a lot of students as attendees. It encourages to strive for a learning culture and being better professionals in software development.

1. Silent talk* about
SOFTWARE AS A CRAFT
This talk happened at the University of Tarragona (URV)
on 17th February 2018
* It includes extra slides as intertitles in the same way as a silent film

2. @bberrycarmen
@codurance_ES
Software as a craft
#DevFestTarragona
@GDGTarragona

3. Thanks ...

4. THANKS ...
@codurance_ES
@verologu
@VanessaGaRe
@GDGTarragona

5. Please, raise a hand if you’ve heard about
Software Craftsmanship
or you are involved in
Software Craftsmanship communities

7. 3 hands were raised

8. Thanks! Please, raise a hand
if you know about
Extreme Programming

10. About 10 hands were raised

11. Thanks! I’m going to talk about
software as a craft
starting with my personal story, very, very briefly

12. Once upon a time ...

13. It began when I was 12 years old and my mother,
programmer in COBOL on punch cards in 70s,
encouraged me to attend a course in the back office of
a printers shop. It was called ‘Soft-Hard academy’ ;)

15. 6 years later,
I had my first computer with a Linux distribution.
My first computer!!!
Those were other times ...

16. 1998

17. 5 years later,
I participated in my first project
following the waterfall method

18. 2003

19. … the (pure) WaterFall method is arrogant in its confidence:
... requirements phase, we will identify all relevant requirements, and
correctly
... analysis and design phases, we will interpret the requirements
correctly, and produce an implementable architecture and design which
will not need changes.
... coding phase, we will interpret the design correctly and make no
significant mistakes
... testing phase, we will test correctly, and (sufficiently) exhaustively
wiki.c2.com
Ward Cunningham

20. Not only a lack of humility,
but also developers are not expected to think.
Experienced developers are promoted to think
and they lose their expertise in programming.

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

22. What happens if we focus on developers?

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

24. Software craftsmanship focuses on
getting better professionals
in software development

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.

26. Two pillars
- Practice
- Master/apprentice
relationship

27. Two pillars
- Practice
- Master/apprentice
relationship

28. There are a lot of available code katas
to practice and to experiment
with principles, patterns, architectures, ...

31. There is a format of event in which
the same code kata is done with different constraints
during a whole day...

32. Coderetreat
Coderetreat is a volunteer-based,
globally coordinated effort
to improve
software developer's skills.
http://coderetreat.org
@coderetreat

33. You can practice alone or with a pair

35. In 1998, Carlos Sainz had a mechanical problem
a few meters from the finish. His co-driver shouted him:
¡Trata de arrancarlo Carlos! ¡Trata de arrancarlo!
(Try to start it, Carlos! Try to start it!)
Until then, I haven’t heard about Luis Moya, his co-driver.

36. 1998

37. A co-driver is very important for a rally driver,
because it’s difficult to become aware of everything
when you are handling controls.
The same thing happens to us with a computer.
So it’s very useful to have a navigator when
programming.

38. DRIVER NAVIGATOR

39. Some recommendations when pair programming

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

41. What can we practice?

42. Evolutionary design?

43. A design discipline:
Test-Driven Development (TDD)

44. Kent Beck says that he ‘rediscovered’ TDD
in an ancient book about programming:
‘It said you take the input tape, manually type in
the output tape you expect, then program until the
actual output tape matches the expected output.’

45. @KentBeck

46. If we start programming production code
and then tests,
we’ll focus on implementation.

47. PRODUCTION
CODE
TEST
CODE
Implementation

48. If we start programming test code
and then production code,
we can focus on behaviour.

49. TEST
CODE
PRODUCTION
CODE
Behaviour/Intention

50. And a step about refactoring can be added,
improving the code, keeping the behaviour.

51. WRITE
TEST CODE
WRITE
PRODUCTION
CODE
REFACTOR

52. Refactor ?

53. Production code & Test code

54. What are the things we can rely on?

55. 4 RULES OF SIMPLE DESIGN

56. Kent Beck wrote these rules after having a bad
experience when accepting this advice..

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. But we can rely on other things...

61. 4RSD
Clean architecture
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

62. And some people tend to think that
they can make it run and right at the same time.
Be humble, wait for listening to the code after green
and then refactor. It will surprise you.

63. WRITE
TEST CODE
WRITE
PRODUCTION
CODE
REFACTOR
HUMILITY

65. A side benefit: coverage

66. Does it make sense only
to focus on a high coverage?
Does it guarantee a good safety net?

68. Let’s imagine balls are mutations of production
code (replacing + by -, reversing conditions, …)
and tests discover/kill those mutations when failing

70. There are tools to mutate source code and
to execute tests in order to detect ‘not-covered’
code

71. Two pillars
- Practice
- Master/apprentice
relationship

72. Having a mentor is a great experience

74. You can find a mentor in your team
or people from who to learn

76. Or you can find them in communities ...

77. https://softwarecrafters.slack.com

78. Or events ...

79. SoCraTes
Software Craftsmanship
retreat for
open-minded craftspeople
who want to improve their craft.

80. Or social networks ...

82. And you can learn a lot when reading books

84. I find it more interesting
to read books about “our history”
(those who don’t know history are doomed to repeat it)
and fundamentals,
rather than about specific languages or frameworks

86. Not only reading ...

87. … but also sharing what you learn.
When you explain what you read,
that knowledge changes for you.
It helps you to comprehend it better.
And you can find small treasures in the first chapters...

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

89. All of this requires time

91. Strive for a learning culture at your work

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

93. And remember ...

94. Master is also apprentice

95. And maintain a balance for a meaningful life

97. @codurance_ES
@bberrycarmen