Neal Ford of ThoughtWorks discusses emergent design and evolutionary architecture. He argues that software design emerges from the code itself, rather than predefined documentation or specifications. Effective abstractions and patterns are discovered through refactoring code written with test-driven development. This approach helps reduce accidental complexity and allows the design to evolve in response to new information and changing requirements.

1. ThoughtWorks
emergent design &
evolutionary architecture
NEAL FORD
software architect / meme wrangler
ThoughtWorks
nford@thoughtworks.com
3003 Summit Boulevard, Atlanta, GA 30319
www.nealford.com
www.thoughtworks.com
memeagora.blogspot.com

2. http://www.ibm.com/developerworks/java/library/j-eaed1/
index.html?S_TACT=105AGX02&S_CMP=EDU
http://tr.im/nf_ead_all

3. agenda

5. things to
think
about

6. emergent
evolutionary

7. Emergent, a.
[L. emergens, p. pr. of emergere.]
1. Rising or emerging out of a fluid
or anything that covers or
conceals; issuing; coming to light.
[1913 Webster]
2. Suddenly appearing; arising
unexpectedly; calling for
prompt action; urgent.
[1913 Webster]

8. spectrum of design
Some
DUF
"Pure"
Waterfall
BDUF
Agile
Emergent
Design
Cowboy
Hacking

9. big design up front
Project Planning/Estimation
Requirements
Use Cases/
Functional Specs
Design
Specifications
Code
Test
Fix/Integrate
$

10. who thought this was a
good idea?

15. emergent (hardware)
design

16. finding abstractions &
patterns

17. Patterns
nomenclature
technical patterns
idiomatic patterns
domain patterns
patterns describe effective abstractions

18. abstracting too early
speculation without facts
YAGNI!
business processes change radically and often
how do you know when?
experience helps
spike solutions

20. emergent
design

21. “what is software design?
design?”
what
Jack C. Reeves
fall 1992, c++ journal
http://www.developerdotstar.com/mag/articles/reeves_design.html

22. software “engineering”
“The final goal of any engineering activity is some
type of documentation”
“When the design effort is complete, the design
documentation is turned over to the manufacturing
team.”
what is the design document in software?
the source code

23. source == design
“...software is cheap to build. It does not qualify as
inexpensive; it is so cheap it is almost free”.
manufacturing == build process
“...software design is easy to create, at least in the
mechanical sense.”
“Given that software designs are relatively easy to
turn out, and essentially free to build, an
unsurprising revelation is that software designs tend
to be incredibly large and complex.”

24. source == design
“...it is cheaper and simpler to just build the design
and test it than to do anything else.”
“The overwhelming problem with software
development is that everything is part of the design
process.”
“Coding is design, testing and debugging are part of
design, and what we typically call software design is
still part of design.”
“Software may be cheap to build, but it is incredibly
expensive to design.”

25. emergent design
discovering design in code
finding effective abstractions
technical abstractions
problem domain abstractions
ability to harvest idiomatic patterns

26. things that
obscure
emergent
design

27. complexity

28. essential complexity
inherent complexity
accidental complexity
all the externally imposed ways that
software becomes complex
essential vs. accidental
complexity

29. examples
Hunting
Season
Essential
EJB / Biztalk
Field Level
Security
Accidental

30. technical
! ! ! debt

31. technical debt

32. technical debt
Code Base
Complexity
principal
effort for
new features
interest

33. negotiating repayment
you must convince someone technical debt
exists...
...start a conversation about repayment
demonstration trumps discussion

34. convincing metrics

35. rampant genericness

36. genericness
“if we build lots of layers for extension, we can
easily build more onto it later”
increases software entropy
accidental complexity
generic obfuscation

38. emergent design
enablers

39. test driven design
more about design than testing
design will emerge from tests
atomic understanding of intent
better abstractions
less accidental complexity

40. perfect number case
study:
∑ of the factors == number
(not including the number)
∑ of the factors - # == #

43. tdd vs test-after
test after doesn’t expose design flaws as early
tdd forces you to think about every little thing
encourages refactoring what’s not right

44. refactoring
collective code ownership
fix broken windows whenever you see them
regularly fix obsolescent abstractions
prudently refactor aggressively
code should get stronger with age

45. refactoring to harvest
idiomatic
patterns

46. cyclomatic complexity
measures complexity of a function
V(G)= e - n + 2
V(G) = cyclomatic complexity of G
e= # edges
n= # of nodes

47. start
if (c1)
1
1
2
f1()
2
f2()
3
4
3
4
if (c2)
5
6
nodes
f3()
5
f4()
6
edges
7
8
7
end

48. afferent coupling
∑ of how many classes use this class
incoming references
determines what is the “hard, crunchy center”
of your code base
measure with CKJM or other metrics tools

49. struts 2.x

50. UIBean evaluateParams()

51. evaluate.*Params ?
find . -name "*.java" | xargs grep -l "void evaluate.*Params" > pbcopy
./org/apache/struts2/components/AbstractRemoteCallUIBean.java
./org/apache/struts2/components/Anchor.java
./org/apache/struts2/components/Autocompleter.java
./org/apache/struts2/components/Checkbox.java
./org/apache/struts2/components/ComboBox.java
./org/apache/struts2/components/DateTimePicker.java
./org/apache/struts2/components/Div.java
./org/apache/struts2/components/DoubleListUIBean.java
./org/apache/struts2/components/DoubleSelect.java
./org/apache/struts2/components/File.java
./org/apache/struts2/components/Form.java
./org/apache/struts2/components/FormButton.java
./org/apache/struts2/components/Head.java
./org/apache/struts2/components/InputTransferSelect.java
./org/apache/struts2/components/Label.java
./org/apache/struts2/components/ListUIBean.java
./org/apache/struts2/components/OptionTransferSelect.java
./org/apache/struts2/components/Password.java
./org/apache/struts2/components/Reset.java
./org/apache/struts2/components/Select.java
./org/apache/struts2/components/Submit.java
./org/apache/struts2/components/TabbedPanel.java
./org/apache/struts2/components/table/WebTable.java
./org/apache/struts2/components/TextArea.java
./org/apache/struts2/components/TextField.java
./org/apache/struts2/components/Token.java
./org/apache/struts2/components/Tree.java
./org/apache/struts2/components/UIBean.java
./org/apache/struts2/components/UpDownSelect.java
!

52. fixing parameters
66 - 9 = 57
lines of
obscuring
duplication
22 * 3 = 66

53. expressiveness
if code is design, readable design matters
complex languages hurt readability
most comments don’t help
not executable
always (potentially) out of date

54. idiomatic “unit of
work” pattern

55. without closures (java)

56. with closures (groovy)

57. with closures (ruby)

58. abstraction styles
imperative
structured / modular
object-oriented
functional
anti-objects

59. collaborative diffusion
“The metaphor of objects can go too far by making
us try to create objects that are too much inspired
by the real world. “
“...an antiobject is a kind of object that appears to
essentially do the opposite of what we generally
think the object should be doing.”

63. architecture

64. Evolution, n.
[L. evolutio an unrolling: cf. F. ['e]
volution evolution
1: a process in which something
passes by degrees to a different
stage (especially a more
advanced or mature stage)

65. application architecture
describes the coarse-grained pieces that
compose an application

66. framework level
architecture
when was the last time you downloaded a
single class?
the unit of reuse in java is the library
JSR 277, the java module system...abandonware
JSR 294 (superpackage)...IN JAVA 7!
implemented by ivy & maven

67. enterprise architecture
concerns itself with how the enterprise as a whole
(which usually means the applications running
inside a large organization) consumes applications

68. enterprise architecture
== city planning

69. application architecture
== building plan

70. extant definitions

72. “The architecture of a software system (at a
given point in time) is its organization or
structure of significant components interacting
through interfaces, those components being
composed of successively smaller components
and interfaces.'"
post on the XP mail list
technical definition

73. "In most successful software projects, the expert
developers working on that project have a
shared understanding of the system design. This
shared understanding is called "architecture."
This understanding includes how the system is
divided into components and how the
components interact through interfaces.'"
Ralph Johnson, rebutting the original post
social definition

74. Architecture is about the
important stuff.
Whatever that is.
Martin Fowler’s definition

75. Stuff that's hard to
change later.
Martin Fowler, in conversation
There should be as little of
that stuff as possible.

76. design
architecture

77. architectural
considerations

78. politics of architecture

79. build or buy

80. business processes are
not commoditizable
“you can buy this generic business process
software...”
“...we just need to tweak it with a few
customizations”
myth
radically unique across similar businesses
software can provide strategic business
advantage

82. Dietzler’s Law
for framework X:
80% of what the user wants is fast & easy
the next 10% is possible but difficult
the last 10% is impossible
users want 100% of what they want

83. standards-based vs.
standardized
flash-back to java web development before j2ee
standards helped developers tremendously...
...but vendors hate it
the price of commodity software quickly
approaches $0
contrast j2ee & sql

84. ESB: standards-based
but not standardized
big enterprise package software touts
standards-based
held together with highly proprietary glue
even the open source ESBs suffer from this
not likely to change
consider the impact on your overall
architecture

86. postlude

87. design == code
other artifacts aid in creating code
all artifacts besides code are transient
irrational artifact attachment

88. last responsible
moment
How can I make my
decision reversible?
Do I need to make
this decision now?
What can I do to
allow me to defer the
decision?

91. ThoughtWorks
for information & more cool stuff,
visit thoughtworks.com
NEAL FORD
software architect / meme wrangler
ThoughtWorks
This work is licensed under the Creative Commons
Attribution-Share Alike 3.0 License.
http://creativecommons.org/licenses/by-sa/3.0/us/
nford@thoughtworks.com
3003 Summit Boulevard, Atlanta, GA 30319
www.nealford.com
www.thoughtworks.com
memeagora.blogspot.com

92. ThoughtWorks
resources
Emergent Design & Evolutionary Architecture
series:
http://tinyurl.com/nf-ead

93. appendix a
Test-after vs. TDD Perfect Number Finder

94. appendix b
Martin Fowler’s Who Needs an Architect