robsmallshire - Agilia Conference 2017

Architecture in the Age of Agile
This
title
is
grammatical
nonsense
because
‘agile’
is
an
adjective.
Robert Smallshire
@robsmallshire
@sixty_north
1
2
3
4
5
The End
6
The End
7
Architecture and Agile
Strange bedfellows or friends with benefits?
Sustainability and Survival
How do we keep it up for two-hundred sprints?
Prediction Models
Doing better than guessing with science.
1
2
3
8
What do we mean?
Nouns, verbs, adjectives
Architecture
Agile
Overlap
9
What do we mean?
Nouns, verbs, adjectives
Architecture
Agile
Overlap
10
What do we mean?
Use to show two overlapping factors
Architecture
Agile
Overlap
11
What do we mean?
Nouns, verbs, adjectives
Architecture
structure
design
frameworks
qualities
review
rules
planning
experience
requirements
Agile
developers
tasks
kanban
code
stories
stand-up
incremental
boxes-and-arrows
#NoEstimates estimates
stakeholders
vision
documentation
retrospective
iterative
validation
process
principles
scrum
YAGNI
testability
tests
team
cost
architects
XP
constraints
product-owner
UML
TDD
up-front
sprint
12
?
agile
13
14
MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS
Dr. Winston W. Rovce
INTRODUCTION
l am going to describe my pe,-.~onal views about managing large software developments. I have had
various assignments during the past nit,.: years, mostly concerned with the development of software packages
for spacecraft mission planning, commanding and post-flight analysis. In these assignments I have experienced
different degrees of successwith respect to arriving at an operational state, on-time, and within costs. I have
become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.
COMPUTER PROGRAM DEVELOPMENT FUNCTIONS
There are two essential steps common to all computer program developments, regardless of size or
complexity. There is first an analysis step, followed second by a coding step as depicted in Figure 1. This sort
of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the
final product is to be operated by those who built it - as is typically done with computer programs for internal
use. It is also the kind of development effort for which most customers are happy to pay, since both steps
involve genuinely creative work which directly contributes to the usefulness of the final product. An
implementation plan to manufacture 13rger software systems, and keyed only to these steps, however, is doomed
• tofailure. Many additional development steps are required, none contribute as directly to the final product as
analysis and coding, and all drive up the development costs. Customer personnel typically would rather not pay
for them, and development personnel would rather not implement them. The prime function of management
is to sell these concepts to both groups and then enforce compliance on the part of development personnel.
Royce, Winston (1970), Managing the Development of Large Software Systems. Proceedings of IEEE WESCON 26 (August): 1–9
15
I
SYSTEM
I
ANALYSIS
PROGRAM
DESIGN
“... the implementation described
above is risky and invites failure”
I
coo,.o
TESTING
I OPERATIONS
Figure 2. Implementation steps to develop a large computer program for delivery to a customer.
Royce, Winston (1970),
1970 Managing the Development of Large Software Systems. Proceedings of IEEE WESCON 26 (August): 1–9
I believe in this concept, but the implementation described above is risky and invites failure. The
16
1970
17
Figure 3.
simulation the project manager is at the mercy of human judgment. With the simulation he can at least
Hopefully,the ~terat=veinteract=onbetweenthe variousphasesis confined to successivesteps.
form experimental tests of some key hypotheses and scope down what remains for human judgment, which
.~oo,.~-,..Sl.,~
he area of computer program design (as in the estimation of takeoff gross weight, costs to complete,
or the
I SYSTEM
I
SYSTEM !
REQUIREMENTSIBI~
y double) is invariably and seriously optimistic.
I
I,,,
1 I
~"'i
PRELIMINARYI%
PROGRAM
DESIGN
spike
s
n
o
i
t
solu ANALYSIS
ANALYSIS I
! PROGRAM I
I
-U
DES,GN
I
"1
I so,w..~ !.
so,w.,~ I
I ANALYSIS
e
v
i
t
a
r
ite
t
n
e
ANALYSIS
m
p
o
l
e
v
de
s
e
s
s
e
proc
PROGRAM
DESIGN
I
~1111~I pRI~OGRAM
i PROGRAM
DESIGN
~lll I
coo,.G I,~
!
TESTING I
I
CODING Ii
O.ATO.S!
Figure4. Unfortunately,for the processillustrated,the designiterationsare neverconfined to the successivesteps.
coo,.o I
330
Dev Ops
TESTING
LI .,s.,.o
USAGE
test
n
e
v
i
r
d
t
n
e
m
p
o
l
e
v
e
d
TESTING
[
OPERATIONS
OPERATIONS
Figure 3. Hopefully,the ~terat=veinteract=onbetweenthe variousphasesis confined to successivesteps.
e 7. Step 3: A t t e m p t to do the job twice - the first result provides an early simulation of the final product.
Royce, Winston (1970),
1970 Managing the Development of Large Software Systems. Proceedings of IEEE WESCON 26 (August): 1–9
18
CODING
eliver a small computer program for internal operations.
Royce, Winston (1970), Managing the Development of Large Software Systems. Proceedings of IEEE WESCON 26 (August): 1–9
19
and keyed only to these steps, however, is doomed
architecture
one contribute as directly to the final product as
ustomer personnel typically would rather not pay
ment them. The prime function of management
liance on the part of development personnel.
over-designed,
intricate
fragmented,
short-lived
just
CODING
malleable,
extensible designs
agile
20
Design and sustainability
What is the effect of doing design on long term viability?
sustainability
"just enough?"
over-designed
over-specific
a little design
goes a long way
design
21
Agile and sustainability
What is the effect of doing agile on long term viability?
sustainability
“nominal agile”
agile adoption
is hard
“real agile”
you can be nimble
with malleable code
agileness
damage
caused by
poor agile
22
23
design
24
agileness
25
26
design
agileness
27
Don't throw the
baby out with
the bathwater!
28
Design
Code
Test
Reduce
batch
sizes!
1 year
1 fortnight
1 minute
29
Test
TDD
Code
Design
30
Tactical and Strategic Design
Responding to events and shaping the future
Agile Development Practices
(Tactics)
Architecture
(Strategic Design)
TDD
Tactical response to actual conditions
High level plan to achieve one or more goals under
conditions of uncertainty.
31
32
“However beautiful the strategy, you
should occasionally look at the results”
Winston Churchill
33
Architecture and Agile
Strange bedfellows or friends with benefits?
Sustainability and Survival
How do we keep it up for two-hundred sprints?
Prediction Models
Doing better than guessing with science.
1
2
3
34
35
36
Required
delivers
The System
Features
facilitates constrains ‘how’
em
deliberate
design for
ain
M
Defects
×1000
cross-cutting
concerns
ab
ilit
y
Qualities
Us
Software
Architecture
Constraints
e
q
r
u
ge
ta
a
in
l
n
i
t
t
a
i
Sc
bi es
lity
ala
bi
lity
Agile
Process
Actual
Sustainable Development
Provision meets ongoing needs whilst preserving
the supporting environment.
38
As an “architect”...
You look after the quality attributes.
The features will look after themselves.
39
Architecture and Agile
Strange bedfellows or friends with benefits?
Sustainability and Survival
How do we keep it up for two-hundred sprints?
Prediction Models
Doing better than guessing with science.
1
2
3
40
Experimental Science
Randomised controlled trials
‣ Developers don’t like to be watched
‣ Eliminating extraneous factors
‣ Toy problems aren’t realistic
‣ No two projects are the same
‣ Can’t do double-blind
‣ Students have little experience
‣ Time and money
41
42
How can we know?
Prediction
1
Formulate a hypothesis.
Validate or refute the model.
Design a conceptual model.
Run simulations.
2
4
Comparison
Modelling
3
Observation
Observe and record reality.
43
Lifetimes in the software industry
Systems and their architectures are long lived
Half-lives of software related entities
The number of years over which half the entities are replaced
3.1
Developers
4.7
Windows XP
6.2
Category Title
Applications
6.8
CEOs
13
Lines of code
22
FTSE100
37
Classes
58
Modules
0
15
30
Sources: Software Lifetime and its Evolution Process over Generations, CEO Succession Practices: 2012 Edition, Investors Chronicle,
45
60
44
Simulating Developer Productivity
Draw teams at random from a productivity distribution
100%
1
50%
0%
cumulative
distribution
function
0
min
10000
mode
triangular
distribution
20000
Productivity SLOC/year
Probability Density
Cumulative Probability
Productivity on 10000 SLOC codebase
30000
max
45
46
Modelling team and code evolution
Use published productivity
data to forward model code
size.
At any given system size we
can predict a distribution for
developer productivity.
Productivity (Lines of Code / Year)
100000
Dramatically less
productive on larger
code bases
29000
10000
5500
1000
100
1000
10000
100000
1000000
10000000
Total Lines of Code
Sources: COCOMO II
47
Simulating a team of seven over five years
when a developer leaves
they are replaced
others
less
start with nothing
After 5 years we
have 235 k lines
of code written
by a total of
19 people.
Only 37% of the
code is by
current team
some developers
contribute more
5 years
48
49
3 years
Team Size : 7
Cumulative team size : 11 ± 2 @ 1σ
157 kLoC
LoC : 157 k ± 23 k @ 1σ
Author present : 70% ± 14% @ 1σ
50
Team Size : 21
20 years
Cumulative team size : 114 ± 9 @ 1σ
1.8 MLoC
LoC : 1.8 M ± 0.08 M @ 1σ
Author present : 19% ± 4% @ 1σ
51
How long for seven to produce 100 000 lines of code?
Probability density from 1000 simulations
0.006
Probability
probability of
delivery on a
particular day
0
0
200
400
Days
600
800
52
How long for 7 to produce 100 000 lines of code?
Cumulative probability from 1000 simulations
Cumulative Probability
100%
probability of
delivery before a
particular day
80%
20%
0%
0
200
330 400 470
Days
600
800
53
Who can you still talk to?
Most authors of your product quit way back when.
The proportion of
code written by
current team
20% after
20 years
days
54
55
Thank you!
Questions?
Robert Smallshire
@robsmallshire
@sixty_north
56
Thank you!
Questions?
Robert Smallshire
@robsmallshire
@sixty_north
57
58
59