The document discusses the evolution of software development, emphasizing the intangible nature of software compared to hardware, and the necessary skills for successful software creation. It highlights the importance of agile methodologies and continuous learning in addressing the complexities of software projects. Additionally, the document raises questions about team dynamics, decision-making, and the overall effectiveness of current software development practices.

1. Software ...and all
that comes with it
alberto.brandolini@avanscoperta.it
twitter: ziobrando

2. Foreword
introducing the speaker

3. About me
In the IT field since ZX Spectrum
Generally in large scale projects (I might be biased)
Freelance consultant: NotOnlyCode
Trainer (Freelance & Skills MaBer + Zenika)
Technical Writer
Blogger: h9p://ziobrando.blogspot.com
TwiBer: ziobrando
My e‐mail:
alberto.brandolini@gmail.com

4. www.avanscoperta.it
avanscoperta.wordpress.com
alberto.brandolini@avanscoperta.it
© Alberto Brandolini 2009

5. Augmented Reality
See what’s around us with different eyes

7. In 1988
John
Carpenter
was already
there

8. In 1988
John
Carpenter
was already
there

14. Part I
Build software
About the step forward done and the ones still to come

15. SoGware
Computer software, or just software is a general term
primarily used for digitally stored data such as computer
programs and other kinds of information read and
written by computers. Today, this includes data that has
not traditionally been associated with computers, such
as film, tapes and records.[1]
The term was coined in order to contrast to the old term
hardware (meaning physical devices); in contrast to
hardware, software is intangible, meaning it "cannot be
touched".[2] Software is also sometimes used in a more
narrow sense, meaning application software only.

16. Main Entry: soft·ware
Pronunciation: ˈsȯft-ˌwer
Function: noun
Date: 1958
: something used or associated with and usually
contrasted with hardware: as a : the entire set of
programs, procedures, and related documentation
associated with a system and especially a computer
system; specifically :computer programs b : materials
for use with audiovisual equipment
A '''computer program tells a computer what to
do. It is a sequence of instructions to be
executed in order. A computer program consists
of a set of instructions that the computer
understands.

17. Hardware: the computer part that
gets hit when the soMware crashes

18. 1) SoMware triggers strong feelings
2) SoMware developers can change
people’s mood

19. A '''computer program tells a computer
what to do. It is a sequence of
instructions to be executed in order. A
computer program consists of a set of
instructions that the computer
understands.

20. soGware is what allows
hardware to do what
the user needs

21. So ...what’s really our job?
Which are the necessary skills?

22. So ...what’s really our job?
Guess?
Which are the necessary skills?

23. So ...what’s really our job?
Guess?
Understand?
Which are the necessary skills?

24. So ...what’s really our job?
Guess?
Do?
Understand?
Which are the necessary skills?

25. So ...what’s really our job?
Guess?
Do?
Understand?
Translate?
Which are the necessary skills?

26. So ...what’s really our job?
Guess?
Do?
Understand?
Translate?
Imagine?
Which are the necessary skills?

27. So ...what’s really our job?
Guess?
Do?
Understand?
Translate?
Imagine? Assemble?
Which are the necessary skills?

28. So ...what’s really our job?
Guess?
Do?
Build?
Understand?
Translate?
Imagine? Assemble?
Which are the necessary skills?

29. Deliver value
Something somewhere is deeply wrong

30. b ud
ge t
The ideal process
a l ue
v
time

31. Might work for some

32. b ud
ge
The ideal waterfall
t
v a l ue
time

33. ...and the real one
b ud
ge t
lu e
v a
time

34. Success or failure?

35. Success!!
b ud
ge t
lu e
Expectations v a
time

36. … more or less

37. bu
dg
et
P.A. Waterfall
v a l ue
time

39. we can do be9er than
this

40. aggressively agile
b ud
ge t
v a l ue
Exp e c t at i o n s

42. Minumum Viable Product
Value Based Planning
ConXnuous deployment
Test driven development
ConXnuous IntegraXon
Code coverage
Business interacXon
...

44. Interlude
Holiday pictures
How to abuse of people’s patience to pretend
that agile and overwheight do not clash

53. 3 easy steps

54. 3 easy steps
Move the first hook

55. 3 easy steps
Move the first hook
Move the second hook

56. 3 easy steps
Move the first hook
Move the second hook
Move to the next plaorm

57. 3 Easy steps

58. 3 Easy steps
Red

59. 3 Easy steps
Red
Green

60. 3 Easy steps
Red
Green
Refactor

63. we can dare the
impossible
... “non regression” is a not ambiXous enough

64. There, where no man has
been before

65. Expectations and
constraints
Are we focusing on the right bottleneck?

66. Things to decide before the start

67. Things to decide before the start
Budget

68. Things to decide before the start
Scope
Budget

69. Things to decide before the start
Staff
Scope
Budget

70. Things to decide before the start
Staff LogisXcs
Scope
Budget

71. Things to decide before the start
Staff LogisXcs
Technology
Scope
Budget

72. Things to decide before the start
Staff LogisXcs
Technology
Scope
Budget
Tools

73. Things to decide before the start
Staff Requirements
LogisXcs
Technology
Scope
Budget
Tools

74. Things to decide before the start
Staff Requirements
LogisXcs
Technology
Process
Scope
Budget
Tools

75. Things to decide before the start
Staff Requirements
LogisXcs
Technology
Process
Scope
Budget
Workplace
Tools

76. Non reversible decisions

77. SoGware architecture is
meant to deal with hardly
reversible decisions…

78. SoGware architecture is
meant to deal with hardly
reversible decisions…
But the most irreversible
decisions have nothing to
do with architecture

79. “Can you
suggest me a
good noise
reduc4on
headset?”

80. Can we really say we’re
doing agile?
How many permissions do we need?
How much potenXal are we missing?
Can we ignore the surroundings?

82. But the worst upfront
decision is...

83. But the worst upfront
decision is...
Legacy

84. Adoring the monolyth

85. Trapped in the Big Ball of Mud

88. Abbiamo i test?

89. Don’t touch the wires
Abbiamo i test?

92. MummificaXon

94. In 2010 (in Italy)
‐ ...a bank to bank payment sUll takes from 2 to
5 days (even with some recent good news)
‐ ...I sUll can’t change a composite train Ucket
online
‐ … more funny things I probably can’t reveal

95. Why so many project

96. Why so many project
‐ Is it the crisis?

97. Why so many project
‐ Is it the crisis?
‐ Or ...the other crisis?

98. Why so many project
‐ Is it the crisis?
‐ Or ...the other crisis?
‐ Or the one before?

99. Why so many project
‐ Is it the crisis?
‐ Or ...the other crisis?
‐ Or the one before?
‐ Or ...did we simply fail to
deliver?

100. IT == wasteOfMoney?

101. How to recover trust?

102. Part II
What are we really doing?
Are we still developing software or ...what?

103. The product
•What’s really the
product?
• How much of this
is soMware?

104. Complexity
Application Complexity
Domain Complexity

105. ...seen by the user
Application Complexity
Domain Complexity
User

106. ...seen by the user
Application Complexity
Domain Complexity
User

107. ...seen by the user
Application Complexity
Domain Complexity
User

108. ...seen by the user
Application Complexity
Domain Complexity
User

109. ...seen by the user
Application Complexity
Domain Complexity
User

110. ...seen by the user
Application Complexity
Domain Complexity
User

111. ...seen by the user
Application Complexity
Domain Complexity
User

112. Interlude
Story of a username

113. Whose ball is this?

114. One product ‐ one team
one product owner with a high level
vision of the product
a team with all the necessary skills to
realize the product

115. for
es s Ar ma
in
us st ch Xo
B ite n
ly Project ct
na
r
designe
Web
A
Manager
ist
ec
UX
ial
QA
sp
Cu
sto Developers
Arc
me
r Coach
hite
ct

116. Have we got all the skills?
skill or roles?
Have we got the structures to work
together?
Are the resources all available?
How?
Under whick contract?
where?
when?
...

118. Part III
Learning
Doing our job better means doing our job
well

119. Noop.nl big Agile PracXces Survey:
“Build a system metaphor”
among the less used agile
pracUces

120. ...what if we try to see it in a different way?
soMware is a side effect of a
learning process

121. • Eliminate waste ‐‐> what is really
necessary? Reduce the cogniXve load
• Amplify learning ‐‐> amplify learning 2 ==
learning to learn
• Decide as late as possible … :‐/
• Deliver as fast as possible ‐‐> short
iteraUons, creaXve collaboraXon with
domain experts, experience on the fiels
• Empower the team ‐‐> empower the
team
• Build integrity in ‐‐> learn consistently
• See the whole ‐‐> no specialists
–

122. Can I plan learning?
Can I learn faster?
Can I learn less things?

123. Primary School Burn Down Chart
10
2
9
3
8
4
7
5
6
6
Numeri
5
7
4
8 Vacanza
3
9
2
1
0
0 1 2 3 4 5 6 7 8 9 10
Settimane

124. 1 2 3 4 5 6 7 8 9 10
2 4 6 8 10 12 14 16 18 20
3 6 9 12 15 18 21 24 27 30
4 8 12 16 20 24 28 32 36 40
5 10 15 20 25 30 35 40 45 50
6 12 18 24 30 36 42 48 54 60
7 14 21 28 35 42 49 56 63 70
8 16 24 32 40 48 56 64 72 80
9 18 27 36 45 54 63 72 81 90
10 20 30 40 50 60 70 80 90 100

125. The art of learning
A few interesting things I found on the topic

126. EducaXon in Finland
school starts at 7
no individual marks unUl the age of
12‐13
self assessment
many group acXviXes
few exams

127. Best Teachers
Survey on teachers that sistema;cally
obtained above the average results in
“heavy” suburbs
No common pracUce ‐‐> conUnuous
evoluXon
Enthusiasm was the only common trait.

128. Montessori method
mulX‐sensorial experience
free experimentaXon
topics and Xmes chosen by students, not
teachers (pull vs push)
no pressure
sXmulaXon environment
one‐on‐one mentoring

129. Esempi vs parole

130. The Rosenthal experiment
Three students group selected as “best
of breed”
Three teachers selected as “best of
breed”
Excellence objecUves
ObjecXves accomplished

131. The Rosenthal experiment
Three students groups selected
randomly
Three teachers selected randomly
Excellence objecUves
ObjecXves accomplished

132. What to learn?
Problem Domain Conventions Admin duties
PMP Legacy code Office space
Project Management Agile
XP TDD
CMMI SOA Domain Driven Design
CQRS
Web 2.0 EDA Scrum
Software Craftmanship Kanban
Back to Basics System Thinking
JQuery Git User Experience
Ruby languages
Scala Erlang Information Architecture

133. Can we do it alone?

134. Swarm learning

135. OrganizaXonal bandwidth
Marketing
another team
team
Domain Experts
offshore team
Operations

136. CommunicaXon tools
Massive improvements possible in the
way we communicate and share
informa4on
Converging on a soluUon is an art
Typical toolset largely insufficient

137. DO
LEARN

138. DO
LEARN

140. Conclusions
… no, really, these are probably more
questions

141. Let’s raise expectaXons:
we can do be9er
we know how to do be9er
it’s legi4mate to ask something
be9er

142. Can we allow our human
capital to deliver?

143. “jumping
around”...

144. “jumping
around”...
...or dare the
impossible?

145. “jumping
around”...
...or dare the
impossible?

146. Stop spoonfeeding the
team
‐Requirements
‐Requirements
‐Requirements
‐Requirements ‐Requirements
‐Requirements
‐Requirements
‐Requirements
‐Requirements
‐Requirements

149. Boss, I have
an idea!

150. Boss, I have
an idea!

151. Boss, I have
an idea!

152. Boss, I have
an idea!

153. Thank You
Tired and hungry, but questions welcome
alberto.brandolini@avanscoperta.it
twitter: ziobrando