The document discusses techniques for software development that are still effective despite attempts to forget them. It presents an analogy that if information technology (IT) were a person, it would be diagnosed with attention deficit hyperactivity disorder (ADHD) due to an inability to focus, retrograde amnesia because it does not recall past experiences, and obsessive-compulsive disorder (OCD) as it follows processes regardless of effectiveness. Old techniques like analysis, architecture, and modeling are discussed as still valuable despite being overlooked at times. Domain-driven design is presented as an example of relearning an old lesson.

1. Nothing New Under the Sun
Techniques that still work no matter how hard we try
to forget them
Nothing New Under the Sun
Slide 1
21 July 2009
Keith Braithwaite
© Zühlke 2010
Context
“I come as an entertainer,
not as a salesman. I want
you to enjoy these ideas
because I enjoy them”—
Alan Watts
Nothing New Under the Sun
Slide 2
21 July 2009
Keith Braithwaite
© Zühlke 2010
1

2. If IT were a person…
It would be diagnosed with
• ADHD
• Retrograde amnesia
• OCD
Nothing New Under the Sun
Slide 3
21 July 2009
Keith Braithwaite
© Zühlke 2010
If IT were a person…
Nothing New Under the Sun
Slide 4
21 July 2009
Keith Braithwaite
© Zühlke 2010
2

3. If IT were a person…
It would be diagnosed with
• ADHD
– We have difficulty retaining focus on the job at hand
– We are very easily distracted by
• Retrograde amnesia
– We don’t recall our past
• OCD
Nothing New Under the Sun
Slide 5
21 July 2009
Keith Braithwaite
© Zühlke 2010
If IT were a person…
It would be diagnosed with
• ADHD
– We have difficulty retaining focus on the job at hand
– We are very easily distracted by
• Retrograde amnesia
– We don’t recall our past
– We don’t recall our past
• OCD
Nothing New Under the Sun
Slide 6
21 July 2009
Keith Braithwaite
© Zühlke 2010
3

4. If IT were a person…
It would be diagnosed with
• ADHD
– We have difficulty retaining focus on the job at hand
– We are very easily distracted by
• Retrograde amnesia
– We don’t recall our past
– We don’t recall our past
• OCD
– We follow rituals independent of their effectiveness
Nothing New Under the Sun
Slide 7
21 July 2009
Keith Braithwaite
© Zühlke 2010
If IT were a person…
It would be diagnosed with
• ADHD
– We have difficulty retaining focus on the job at hand
– We are very easily distracted by
• Retrograde amnesia
– We don’t recall our past
– We don’t recall our past
• OCD
– We follow rituals independent of their effectiveness
Nothing New Under the Sun
Slide 8
21 July 2009
Keith Braithwaite
© Zühlke 2010
4

5. Tony Hoare said…
“If we could only learn the
right lessons from the
successes of the past we
would not need to learn from
the failures ”
Nothing New Under the Sun
Slide 9
21 July 2009
Keith Braithwaite
© Zühlke 2010
Zombies
www.flickr.com/photos/ hryckowian/3540744713/
Nothing New Under the Sun
Slide 10
21 July 2009
Keith Braithwaite
© Zühlke 2010
5

6. Zombies
Given half a chance they will eat your brain
• Code the works “first time”
• Structured Programming
These, and others, we should forget
Nothing New Under the Sun
Slide 11
21 July 2009
Keith Braithwaite
© Zühlke 2010
Code that works “first time”
City and Guilds COBOL
• 3 attempts to compile, run and test or fail
There was a time when this sort of thing made sense
Nothing New Under the Sun
Slide 12
21 July 2009
Keith Braithwaite
© Zühlke 2010
6

7. Code that works “first time”
There was a time when this sort of thing made sense
Nothing New Under the Sun
Slide 13
21 July 2009
Keith Braithwaite
© Zühlke 2010
Code that works “first time”
Jerry Weinberg tells of being told that
• Thecomputer (singular) earns more than you do, so
behave accordingly
Nothing New Under the Sun
Slide 14
21 July 2009
Keith Braithwaite
© Zühlke 2010
7

8. Code that works “first time”
The computer learns more than you, behave accordingly
• cost(processor time) >> cost(developer time)
• Cycle time to get feedback—hours to days
Nothing New Under the Sun
Slide 15
21 July 2009
Keith Braithwaite
© Zühlke 2010
Code that works “first time”
The computer learns more than you, behave accordingly
• cost(processor time) >> cost(developer time)
• Cycle time to get feedback—hours to days
In fact, you earn much more than the computer
Nothing New Under the Sun
Slide 16
21 July 2009
Keith Braithwaite
© Zühlke 2010
8

9. Code that works “first time”
The computer learns more than you, behave accordingly
• cost(processor time) >> cost(developer time)
• Cycle time to get feedback—hours to days
You earn much more than the computer, behave accordingly
• cost(processor time) << cost(developer time)
• Cycle time to get feedback—milliseconds to minutes
• A top-end dev workstation amortised over 3 years
– £1 per day
– 2 or 3 orders of magnitude cheaper than a programmer Nothing New Under the Sun
Slide 17
21 July 2009
behave accordingly
Keith Braithwaite
© Zühlke 2010
Code that works “first time”
low Uncertainty high
high
ch
cs
ao
liti
s
po
Disagreement
sim
pli
gy
c ity
olo
Nothing New Under the Sun
Slide 18
ide
21 July 2009
low
Keith Braithwaite
© Zühlke 2010
9

10. Code that works “first time”
low Uncertainty high
high
N
pr ovel
ac
pr ood
e
tic
tic
e
ac
G
Disagreement
Be
st
Pr
ac e
pr od
tic
tic
Go
Nothing New Under the Sun
e
ac
Slide 19
21 July 2009
low
Keith Braithwaite
© Zühlke 2010
Code that works “first time”
low Uncertainty high
high
Sense ActNo
pr vel
ac
pr ood
e
tic
Analyze Sense tic
e
ac
G
Disagreement
Respond Respond
Sense
Be Sense
st
Pr
Categorize Analyze
ac
e
pr od
tic
tic
Go
Nothing New Under the Sun
e
ac
Slide 20
Respond Respond
21 July 2009
low
Keith Braithwaite
© Zühlke 2010
10

11. Old School: things we got right
Nothing New Under the Sun
Slide 21
21 July 2009
http://commons.wikimedia.org/wiki/File:Vincent_Series_C_Black_Shadow_1950.jpg Keith Braithwaite
© Zühlke 2010
Old School: things we got right
Nothing New Under the Sun
Slide 22
21 July 2009
Keith Braithwaite
http://www.digibarn.com/collections/screenshots/xerox-star-8010/xerox-star-8010-02.jpg © Zühlke 2010
11

12. Old School: things we got right
Analysis
Architecture
Modelling
Nothing New Under the Sun
Slide 23
21 July 2009
http://commons.wikimedia.org/wiki/File:Vincent_Series_C_Black_Shadow_1950.jpg Keith Braithwaite
© Zühlke 2010
Analysis
There used to be this thing called Systems Analysis
• It used to be a core skill
• But it got a bad name
Nothing New Under the Sun
Slide 24
21 July 2009
Keith Braithwaite
© Zühlke 2010
12

13. Analysis
So, we stopped doing it
• Agile gave some of us an excuse
Nothing New Under the Sun
Slide 25
21 July 2009
Keith Braithwaite
© Zühlke 2010
Analysis
We had to re-invent understanding
• Behaviour Driven Development
– (AKA TDD the way you were always supposed to do it)
• Domain Driven Design
– “Until I started working in "enterprise IT" I didn't realize that people didn't
do this. I suppose that this is an important book, but it's depressing that this
is so”—Nat Pryce
Nothing New Under the Sun
Slide 26
21 July 2009
Keith Braithwaite
© Zühlke 2010
13

14. Analysis
Domain Driven Design
“Leading software designers have recognized domain
modeling and design as critical topics for at least 20
years, yet surprisingly little has been written about what
needs to be done or how to do it.”—Evans
Nothing New Under the Sun
Slide 27
21 July 2009
Keith Braithwaite
© Zühlke 2010
Syntropy
Three Perspectives:
• Essential
• Specification
• Implementation
Three Kinds of Domain
• Concept
• Interaction
• Infrastructure
Nothing New Under the Sun
Slide 28
11 March 2010
http://www.syntropy.co.uk/syntropy/designing-object-systems.pdf
Keith Braithwaite
© Zühlke 2010
14

15. Syntropy: Essential Perspective
Essential models talk about
• (someone’s understanding of)
• (a part of)
• (a situation in)
The World
• Objects with observable state, identity
• Globally broadcast, instantaneous events
• Objects change state in response to events Nothing New Under the Sun
– Not “message sending” Slide 29
11 March 2010
Keith Braithwaite
© Zühlke 2010
Syntropy: Specification Perspective
Specification models talk about a (proposed) system
“At some point during a development (which may or
may not be at the beginning), the interface at the
boundary between the software and its
environment must be specified, and the
specification model provides a way to specify this
interface precisely.”—Cook and Daniels §6.1 emphasis in
original
• Objects with observable state, identity
• Globally broadcast, instantaneous events
Nothing New Under the Sun
Slide 30
• Objectschange state in response to events and 11 March 2010
generate new events
Keith Braithwaite
© Zühlke 2010
15

16. Syntropy: Implementation Perspective
Implementation models talk about design
• Objects
with observable state, identity, and
responsibilities
• Point-to-point messages
• Objects
change state in response to messages and
send new messages
Nothing New Under the Sun
Slide 31
11 March 2010
Keith Braithwaite
© Zühlke 2010
Syntropy: Domains
Three kinds of domain
• Interaction: at the system boundary
• Concept: what the system is about
• Infrastructure: How it works
Essential Perspective models concentrate
on concept domains
Specification Perspective models have
Interaction domains
Kiln control system, Cook and Daniels fig 11.2
Implementation Perspective models have Nothing New Under the Sun
Slide 32
all three
11 March 2010
Keith Braithwaite
© Zühlke 2010
16

17. Syntropy: Relationship Between Models
“…the main correspondence between all three
[perspectives] is in the type views for the concept
domains.” —Cook and Daniels §10.3 emphasis in
original
“State diagrams do not, in general, correspond
between essential and specification models.” —ibid
Nothing New Under the Sun
Slide 33
11 March 2010
Keith Braithwaite
© Zühlke 2010
Syntropy: The System Boundary
“If the software boundary is implicit in the situation
itself, essential modelling may not be very helpful,
because the essential model would express the
same behaviour as the specification model without
specifying which events are software-generated.
However, when the software boundary is to be
designed, an essential model provides a systematic
way of designing it.” —Cook and Daniels §10.5
Nothing New Under the Sun
Slide 34
11 March 2010
Keith Braithwaite
© Zühlke 2010
17

18. Aside: Diagnostic Instrument
If everyone agrees that it’s obviously correct:
• That the system has layers
• The one at the “top” is a website
• The one at the bottom is a database
Then:
• You probably don’t have much of a domain
• Notethat adding an ORM layer does not magically
create a domain
Nothing New Under the Sun
Slide 35
11 March 2010
Keith Braithwaite
© Zühlke 2010
Syntropy: Implications
There is no “seamlessness”
• From world to spec to system requires translation
You can’t sensibly use exactly one modelling language:
• To understand the world
• To specify a system
• To design an implementation
Nothing New Under the Sun
Slide 36
11 March 2010
Keith Braithwaite
© Zühlke 2010
18

19. Problem Frames
“The problem is not at the computer interface—it is
deeper into the world, further away form the
computer”—Jackson Problem Frames §1.4
“Many descriptions that aught to be about the world
[…] are really about the computer and the
software”—ibid §1.7
“Not everything worth thinking about has to result in a
piece of program text or a designed domain. And
conversely, the fact that there will be no model of
[some things] doesn’t mean that you don’t have to
describe them in your problem analysis” —ibid §2. Nothing New Under the Sun
Slide 37
11 March 2010
Keith Braithwaite
© Zühlke 2010
Problem Frame: Required Behaviour
The Control Machine, which is to be built,
directs Causal Phenomena (C1) at the Control
Controlled Domain Machine
The Controlled Domain may respond with CM!C1 CD!C2
Causal Phenomena (C2) to provide feedback
The Controlled Domain is a a Causal Domain, so Controlled
we can predict how C2 depends on C1 Domain
C
The Required Behaviour specifies some Causal
Phenomena (C3) which must be satisfied if C3
the Control Machine is to be correct Nothing New Under the Sun
Required
Slide 38
Example: timed traffic lights
11 March 2010
Behaviour
Keith Braithwaite
© Zühlke 2010
19

20. Problem Frame: Commanded Behaviour
The Control Machine and Controlled
Domain interact as in Required Control
Behaviour Machine
Additionally an Operator observes events in OP!E4 CD!C2
the context of the Commanded CM!C1
Behaviour (such as E4) and sends
commands to the control machine Operator Controlled
Domain
The Operator is a merely “biddable” B C
domain, we cannot predict to a certainty
C3
how E4 and C3 are related E4
Nothing New Under the Sun
Example: opening or closing a sluicegate Commanded
Slide 39
11 March 2010
under manual control Behaviour
Keith Braithwaite
© Zühlke 2010
Problem Frame: Information Display
The Real World is a Causal Domain, but an
automomous, active one. It does it’s own Information
thing. It shares causal phenomena (such as Machine
C1) with the Information Machine.
The Information Machine sends events (E2) IM!E2 RW!C1
to the Display (also a Causal Domain)
Display Real World
The Display updates shared symbolic values
(such as Y4) which must reflect C C
phenomena C shared with the Real World,
C3
but which can only be inferred from C1 Y4
Nothing New Under the Sun
Example: vehicle odometer Display~Real
Slide 40
11 March 2010
World
Keith Braithwaite
© Zühlke 2010
20

21. Problem Frame: Simple Workpieces
The Editing Tool can send commands (in the
form of events such as E1) to the work Editing
pieces. Tool
The workpieces are are leXical domain and US!E3 WP!Y2
may present symbolic phenomena (Y2) ET!E1
to the Editing Tool.
User Work
The User may send events (E3) reflecting Pieces
their desires for the workpieces. B X
Example: a party planning tool Y4
E3
Nothing New Under the Sun
Command
Slide 41
11 March 2010
Effects
Keith Braithwaite
© Zühlke 2010
Problem Frame: Transformation
The Transform Machine notes symbolic
phenomena (such as Y1) as input and Transform
emits symbolic phenomena (such as Machine
Y2) as output.
TM!Y2 IN!Y1
Input and Output are both lexical domains.
Example: email statistics analyser Outputs Inputs
X X
Y3
Y4
Nothing New Under the Sun
IO Relation
Slide 42
11 March 2010
Keith Braithwaite
© Zühlke 2010
21

22. Problem Frames: Three Descriptions
Three different things, three different descriptions
• The requirement is in the world
• The specification is at the system interface
• The domains join them up
Real problems have multiple, overlapping frames
• The book contains much guidance on managing this
Nothing New Under the Sun
Slide 43
11 March 2010
Keith Braithwaite
© Zühlke 2010
Problem Frames: The aspiration
“Ideally, each problem frame would be associate with
a systematic method that is known to be effective
for analyzing and solving any problem that fits the
frame”
Nothing New Under the Sun
Slide 44
11 March 2010
Keith Braithwaite
© Zühlke 2010
22

23. Re–invention
About 20 years ago a bunch of really smart people
thought really hard about domains and their
relationship to design.
They came up with a bunch of really good ideas, and
about 15 years ago, wrote them down.
We had to re–invent the idea of understanding
domains as a guide to building systems
Are we going to have to re–discover those good ideas,
too?
Nothing New Under the Sun
Slide 45
11 March 2010
Keith Braithwaite
© Zühlke 2010
Not Doing Your Homework
—Oliver Heaviside, 1884
Nothing New Under the Sun
Slide 46
11 March 2010
Keith Braithwaite
© Zühlke 2010
23

24. Not Doing Your Homework
Domain Driven Design
“Leading software designers have recognized domain
modeling and design as critical topics for at least 20
years, yet surprisingly little has been written about what
needs to be done or how to do it.”—Evans
But what has been written contains valuable lessons
Maybe it would be worth looking…
Nothing New Under the Sun
Slide 47
21 July 2009
Keith Braithwaite
© Zühlke 2010
24