0
ThoughtWorks




       emergent design &
evolutionary architecture
                 NEAL FORD        software architect /...
http://www.ibm.com/developerworks/java/library/j-eaed1/
     index.html?S_TACT=105AGX02&S_CMP=EDU
                 http://...
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
   ...
spectrum of design
 "Pure"            Some
                            Agile
Waterfall          DUF




                  ...
big design up front
Project Planning/Estimation

      Requirements


                          Use Cases/
               ...
who thought this was a
     good idea?
emergent (hardware)
      design
finding abstractions &
      patterns
Patterns
 nomenclature

    technical patterns
idiomatic patterns
    domain patterns

 patterns describe effective abstra...
abstracting too early
speculation without facts

YAGNI!

business processes change radically and often

how do you know wh...
emergent
  design
“what is software design?
 what             design?”

                      Jack C. Reeves
                 fall 1992, c++...
software “engineering”
“The final goal of any engineering activity is some
type of documentation”

“When the design effort ...
source == design
“...software is cheap to build. It does not qualify as
inexpensive; it is so cheap it is almost free”.
ma...
source == design
“...it is cheaper and simpler to just build the design
and test it than to do anything else.”
“The overwh...
emergent design
discovering design in code

finding effective abstractions

   technical abstractions

   problem domain ab...
things that
  obscure
 emergent
   design
complexity
essential complexity
inherent complexity

accidental complexity
all the externally imposed ways that
software becomes comp...
examples
     Hunting
     Season                  EJB / Biztalk



               Field Level
                Security
Es...
technical
! ! ! debt
technical debt
technical debt




Code Base                   effort for
Complexity   principal     new features

                       ...
negotiating repayment
you must convince someone technical debt
exists...


...start a conversation about repayment



demo...
convincing metrics
rampant genericness
genericness

“if we build lots of layers for extension, we can
easily build more onto it later”

increases software entrop...
emergent design
enablers
test driven design
more about design than testing

design will emerge from tests

atomic understanding of intent

better a...
perfect number case
       study:
 ∑ of the factors == number
 (not including the number)

  ∑ of the factors - # == #
tdd vs test-after

test after doesn’t expose design flaws as early



tdd forces you to think about every little thing



e...
refactoring
collective code ownership

fix broken windows whenever you see them

regularly fix obsolescent abstractions

pru...
refactoring to harvest
      idiomatic     patterns
cyclomatic complexity
  measures complexity of a function

 V(G)= e - n + 2
 V(G) = cyclomatic complexity of G
 e= # edges...
start




                       1               if (c1)
                                                         1



   ...
afferent coupling
∑ of how many classes use this class


incoming references

determines what is the “hard, crunchy center...
struts 2.x
UIBean evaluateParams()
evaluate.*Params ?
  find . -name "*.java" | xargs grep -l "void evaluate.*Params" > pbcopy


./org/apache/struts2/componen...
fixing parameters
               66 - 9 = 57
                 lines of
                obscuring
               duplication...
expressiveness
if code is design, readable design matters

complex languages hurt readability

most comments don’t help

 ...
idiomatic “unit of
  work” pattern
without closures (java)
with closures (groovy)
with closures (ruby)
abstraction styles
imperative

   structured / modular

   object-oriented

functional

anti-objects
collaborative diffusion
“The metaphor of objects can go too far by making
us try to create objects that are too much inspi...
architecture
Evolution, n.
[L. evolutio an unrolling: cf. F. ['e]
volution evolution

 1: a process in which something
    passes by de...
application architecture
describes the coarse-grained pieces that
compose an application
framework level
          architecture
when was the last time you downloaded a
single class?

the unit of reuse in java is...
enterprise architecture
concerns itself with how the enterprise as a whole
  (which usually means the applications running...
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 compo...
"In most successful software projects, the expert
    developers working on that project have a
 shared understanding of t...
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 s...
design




architecture
architectural
considerations
politics of architecture
build or buy
business processes are
   not commoditizable
“you can buy this generic business process
software...”
“...we just need to t...
Dietzler’s Law
for framework X:

  80% of what the user wants is fast & easy

  the next 10% is possible but difficult

  t...
standards-based vs.
        standardized
flash-back to java web development before j2ee

standards helped developers tremen...
ESB: standards-based
   but not standardized
big enterprise package software touts
standards-based

held together with hig...
postlude
design == code
other artifacts aid in creating code

all artifacts besides code are transient

irrational artifact attachm...
last responsible
               moment
                     How can I make my
                     decision reversible?


...
ThoughtWorks




              for information & more cool stuff,
                   visit thoughtworks.com

             ...
ThoughtWorks




              resources
Emergent Design & Evolutionary Architecture
series:

  http://tinyurl.com/nf-ead
appendix a
Test-after vs. TDD Perfect Number Finder
appendix b
Martin Fowler’s Who Needs an Architect
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Neal Ford Emergent Design And Evolutionary Architecture
Upcoming SlideShare
Loading in...5
×

Neal Ford Emergent Design And Evolutionary Architecture

8,465

Published on

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.

Published in: Technology
2 Comments
17 Likes
Statistics
Notes
No Downloads
Views
Total Views
8,465
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
419
Comments
2
Likes
17
Embeds 0
No embeds

No notes for slide

Transcript of "Neal Ford Emergent Design And Evolutionary Architecture"

  1. 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. 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. 3. agenda
  4. 4. things to think about
  5. 5. emergent evolutionary
  6. 6. 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]
  7. 7. spectrum of design "Pure" Some Agile Waterfall DUF Emergent Cowboy BDUF Design Hacking
  8. 8. big design up front Project Planning/Estimation Requirements Use Cases/ Functional Specs Design Specifications Code Test Fix/Integrate $
  9. 9. who thought this was a good idea?
  10. 10. emergent (hardware) design
  11. 11. finding abstractions & patterns
  12. 12. Patterns nomenclature technical patterns idiomatic patterns domain patterns patterns describe effective abstractions
  13. 13. abstracting too early speculation without facts YAGNI! business processes change radically and often how do you know when? experience helps spike solutions
  14. 14. emergent design
  15. 15. “what is software design? what design?” Jack C. Reeves fall 1992, c++ journal http://www.developerdotstar.com/mag/articles/reeves_design.html
  16. 16. 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
  17. 17. 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.”
  18. 18. 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.”
  19. 19. emergent design discovering design in code finding effective abstractions technical abstractions problem domain abstractions ability to harvest idiomatic patterns
  20. 20. things that obscure emergent design
  21. 21. complexity
  22. 22. essential complexity inherent complexity accidental complexity all the externally imposed ways that software becomes complex essential vs. accidental complexity
  23. 23. examples Hunting Season EJB / Biztalk Field Level Security Essential Accidental
  24. 24. technical ! ! ! debt
  25. 25. technical debt
  26. 26. technical debt Code Base effort for Complexity principal new features interest
  27. 27. negotiating repayment you must convince someone technical debt exists... ...start a conversation about repayment demonstration trumps discussion
  28. 28. convincing metrics
  29. 29. rampant genericness
  30. 30. genericness “if we build lots of layers for extension, we can easily build more onto it later” increases software entropy accidental complexity generic obfuscation
  31. 31. emergent design enablers
  32. 32. test driven design more about design than testing design will emerge from tests atomic understanding of intent better abstractions less accidental complexity
  33. 33. perfect number case study: ∑ of the factors == number (not including the number) ∑ of the factors - # == #
  34. 34. 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
  35. 35. refactoring collective code ownership fix broken windows whenever you see them regularly fix obsolescent abstractions prudently refactor aggressively code should get stronger with age
  36. 36. refactoring to harvest idiomatic patterns
  37. 37. cyclomatic complexity measures complexity of a function V(G)= e - n + 2 V(G) = cyclomatic complexity of G e= # edges n= # of nodes
  38. 38. start 1 if (c1) 1 2 2 f1() 3 f2() 4 4 3 if (c2) 5 6 nodes 5 f3() 6 f4() edges 7 8 7 end
  39. 39. 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
  40. 40. struts 2.x
  41. 41. UIBean evaluateParams()
  42. 42. evaluate.*Params ? find . -name "*.java" | xargs grep -l "void evaluate.*Params" > pbcopy ./org/apache/struts2/components/AbstractRemoteCallUIBean.java ./org/apache/struts2/components/Label.java ./org/apache/struts2/components/Anchor.java ./org/apache/struts2/components/ListUIBean.java ./org/apache/struts2/components/Autocompleter.java ./org/apache/struts2/components/OptionTransferSelect.java ! ./org/apache/struts2/components/Checkbox.java ./org/apache/struts2/components/Password.java ./org/apache/struts2/components/ComboBox.java ./org/apache/struts2/components/Reset.java ./org/apache/struts2/components/DateTimePicker.java ./org/apache/struts2/components/Select.java ./org/apache/struts2/components/Div.java ./org/apache/struts2/components/Submit.java ./org/apache/struts2/components/DoubleListUIBean.java ./org/apache/struts2/components/TabbedPanel.java ./org/apache/struts2/components/DoubleSelect.java ./org/apache/struts2/components/table/WebTable.java ./org/apache/struts2/components/File.java ./org/apache/struts2/components/TextArea.java ./org/apache/struts2/components/Form.java ./org/apache/struts2/components/TextField.java ./org/apache/struts2/components/FormButton.java ./org/apache/struts2/components/Token.java ./org/apache/struts2/components/Head.java ./org/apache/struts2/components/Tree.java ./org/apache/struts2/components/InputTransferSelect.java ./org/apache/struts2/components/UIBean.java ./org/apache/struts2/components/UpDownSelect.java
  43. 43. fixing parameters 66 - 9 = 57 lines of obscuring duplication 22 * 3 = 66
  44. 44. expressiveness if code is design, readable design matters complex languages hurt readability most comments don’t help not executable always (potentially) out of date
  45. 45. idiomatic “unit of work” pattern
  46. 46. without closures (java)
  47. 47. with closures (groovy)
  48. 48. with closures (ruby)
  49. 49. abstraction styles imperative structured / modular object-oriented functional anti-objects
  50. 50. 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.”
  51. 51. architecture
  52. 52. 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)
  53. 53. application architecture describes the coarse-grained pieces that compose an application
  54. 54. 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
  55. 55. enterprise architecture concerns itself with how the enterprise as a whole (which usually means the applications running inside a large organization) consumes applications
  56. 56. enterprise architecture == city planning
  57. 57. application architecture == building plan
  58. 58. extant definitions
  59. 59. “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
  60. 60. "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
  61. 61. Architecture is about the important stuff. Whatever that is. Martin Fowler’s definition
  62. 62. Stuff that's hard to change later. Martin Fowler, in conversation There should be as little of that stuff as possible.
  63. 63. design architecture
  64. 64. architectural considerations
  65. 65. politics of architecture
  66. 66. build or buy
  67. 67. 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
  68. 68. 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
  69. 69. 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
  70. 70. 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
  71. 71. postlude
  72. 72. design == code other artifacts aid in creating code all artifacts besides code are transient irrational artifact attachment
  73. 73. 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?
  74. 74. ThoughtWorks for information & more cool stuff, visit thoughtworks.com NEAL FORD software architect / meme wrangler ThoughtWorks This work is licensed under the Creative Commons nford@thoughtworks.com Attribution-Share Alike 3.0 License. 3003 Summit Boulevard, Atlanta, GA 30319 www.nealford.com www.thoughtworks.com http://creativecommons.org/licenses/by-sa/3.0/us/ memeagora.blogspot.com
  75. 75. ThoughtWorks resources Emergent Design & Evolutionary Architecture series: http://tinyurl.com/nf-ead
  76. 76. appendix a Test-after vs. TDD Perfect Number Finder
  77. 77. appendix b Martin Fowler’s Who Needs an Architect
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×