neal ford emergent design and evolutionary architecture
DESCRIPTION
ThoughtWorks Luminary and Conference Presenter Extraordinaire Neal Ford will be presenting: Emergent Design & Evolutionary Architecture Most of the software world has realised that Big Design Up Front (BDUF) doesn’t work well in software. But lots of developers struggle with this notion when it applies to architecture and design, surely you can’t start coding, right? You need some level of understanding before you can start work. This seminar will explore the current thinking about Emergent Design and Evolutionary Architecture, including: • Proactive approaches with test driven development • Reactive approaches including both refactoring and composed methods • Strategies and techniques for allowing design to emerge from projects as they proceed, keeping your code in sync with the problem domain • Real world examples of these techniques in action Neal Ford, Software Architect and Meme Wrangler, ThoughtWorks Neal is an acclaimed international speaker and expert on designing and building of large-scale enterprise applications. Neal has spoken at over 100 conferences worldwide, delivering more than 600 talks. Neal is also the designer and developer of applications, instructional materials, magazine articles, courseware, video/DVD presentations and author and/or editor of 6 books spanning a variety of technologies, including the most recent The Productive Programmer.TRANSCRIPT
ThoughtWorksThoughtWorks
NEAL FORD software architect / meme wrangler
ThoughtWorks
[email protected] 3003 Summit Boulevard, Atlanta, GA 30319
www.nealford.com
www.thoughtworks.com
memeagora.blogspot.com
emergent design & evolutionary architecture
http://www.ibm.com/developerworks/java/library/j-eaed1/index.html?S_TACT=105AGX02&S_CMP=EDU
http://tr.im/nf_ead_all
agenda
things to think about
emergent evolutionary
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]
spectrum of design
"Pure" Waterfall
Emergent Design
Agile
BDUFCowboyHacking
Some DUF
big design up front
Project Planning/Estimation
Requirements
Use Cases/Functional Specs
Design Specifications
Code
Test
Fix/Integrate $
who thought this was a good idea?
emergent (hardware) design
finding abstractions & patterns
domain patterns
nomenclature
technical patterns
patterns describe effective abstractions
Patterns
patternsidiomatic
business processes change radically and often
speculation without facts
YAGNI!
spike solutions
how do you know when?
abstracting too early
experience helps
emergent design
what is software design?
Jack C. Reevesfall 1992, c++ journal
http://www.developerdotstar.com/mag/articles/reeves_design.html
“what is software design?”
what is the design document in software?
“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.”
the source code
software “engineering”
“...software design is easy to create, at least in the mechanical sense.”
“...software is cheap to build. It does not qualify as inexpensive; it is so cheap it is almost free”.
manufacturing == build process
“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.”
source == design
“Coding is design, testing and debugging are part of design, and what we typically call software design is still part of 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.”
“Software may be cheap to build, but it is incredibly expensive to design.”
source == design
technical abstractions
discovering design in code
finding effective abstractions
ability to harvest idiomatic patterns
problem domain abstractions
emergent design
things that obscure
emergent design
complexity
essential vs. accidental complexity
accidental complexityall the externally imposed ways that software becomes complex
essential complexityinherent complexity
Hunting Season
Field Level Security
EJB / Biztalk
Essential Accidental
examples
technical ! ! ! debt
technical debt
Code Base Complexity principal
interest
effort for new features
technical debt
demonstration trumps discussion
you must convince someone technical debt exists...
...start a conversation about repayment
negotiating repayment
convincing metrics
rampant genericness
increases software entropy
“if we build lots of layers for extension, we can easily build more onto it later”
generic obfuscation
accidental complexity
genericness
emergent design enablers
atomic understanding of intent
more about design than testing
design will emerge from tests
less accidental complexity
better abstractions
test driven design
perfect number case study:
∑ of the factors == number(not including the number)
∑ of the factors - # == #
tdd forces you to think about every little thing
test after doesn’t expose design flaws as early
encourages refactoring what’s not right
tdd vs test-after
regularly fix obsolescent abstractions
collective code ownership
fix broken windows whenever you see them
code should get stronger with age
prudently refactor aggressively
refactoring
refactoring to harvest idiomatic patterns
cyclomatic complexitymeasures complexity of a function
V(G)= e - n + 2V(G) = cyclomatic complexity of Ge= # edgesn= # of nodes
start
if (c1)
f1() f2()
if (c2)
f3() f4()
end
start
if (c1)
f1() f2()
if (c2)
f3() f4()
end
7
65
4
32
1
8
7
65
4
3
2
1
nodes
edges
determines what is the “hard, crunchy center” of your code base
∑ of how many classes use this class
incoming references
measure with CKJM or other metrics tools
afferent coupling
struts 2.x
UIBean evaluateParams()
evaluate.*Params ?
./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
find . -name "*.java" | xargs grep -l "void evaluate.*Params" > pbcopy
!
fixing parameters
22 * 3 = 66
66 - 9 = 57lines of
obscuring duplication
most comments don’t help
if code is design, readable design matters
complex languages hurt readability
always (potentially) out of date
not executable
expressiveness
idiomatic “unit of work” pattern
without closures (java)
with closures (groovy)
with closures (ruby)
object-oriented
imperative
structured / modular
anti-objects
functional
abstraction styles
“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.”
collaborative diffusion
architecture
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)
describes the coarse-grained pieces that compose an application
application architecture
JSR 277, the java module system...abandonware
when was the last time you downloaded a single class?
the unit of reuse in java is the library
implemented by ivy & maven
JSR 294 (superpackage)...IN JAVA 7!
framework level architecture
enterprise architectureconcerns itself with how the enterprise as a whole
(which usually means the applications running inside a large organization) consumes applications
enterprise architecture == city planning
application architecture == building plan
extant definitions
“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
Ralph Johnson, rebutting the original post
"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.'"
social definition
Architecture is about the important stuff.
Whatever that is.
Martin Fowler’s definition
Stuff that's hard to change later.
Martin Fowler, in conversation
There should be as little of that stuff as possible.
architecture
design
architectural considerations
politics of architecture
build or buy
“...we just need to tweak it with a few customizations”
radically unique across similar businesses
“you can buy this generic business process software...”
software can provide strategic business advantage
myth
business processes are not commoditizable
the next 10% is possible but difficult
for framework X:
80% of what the user wants is fast & easy
users want 100% of what they want
the last 10% is impossible
Dietzler’s Law
...but vendors hate it
flash-back to java web development before j2ee
standards helped developers tremendously...
contrast j2ee & sql
the price of commodity software quickly approaches $0
standards-based vs. standardized
even the open source ESBs suffer from this
big enterprise package software touts standards-based
held together with highly proprietary glue
consider the impact on your overall architecture
not likely to change
ESB: standards-based but not standardized
postlude
other artifacts aid in creating code
all artifacts besides code are transient
irrational artifact attachment
design == code
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?
last responsible moment
ThoughtWorks
This work is licensed under the Creative Commons Attribution-Share Alike 3.0 License.
http://creativecommons.org/licenses/by-sa/3.0/us/
for information & more cool stuff, visit thoughtworks.com
NEAL FORD software architect / meme wrangler
ThoughtWorks
[email protected] 3003 Summit Boulevard, Atlanta, GA 30319
www.nealford.com
www.thoughtworks.com
memeagora.blogspot.com
resources
ThoughtWorks
http://tinyurl.com/nf-ead
Emergent Design & Evolutionary Architecture series:
appendix aTest-after vs. TDD Perfect Number Finder
appendix bMartin Fowler’s Who Needs an Architect