Neal Ford Emergent Design And Evolutionary Architecture


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
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Neal Ford Emergent Design And Evolutionary Architecture

  1. 1. ThoughtWorks emergent design & evolutionary architecture NEAL FORD software architect / meme wrangler ThoughtWorks 3003 Summit Boulevard, Atlanta, GA 30319
  2. 2. index.html?S_TACT=105AGX02&S_CMP=EDU
  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 Some DUF "Pure" Waterfall BDUF Agile Emergent Design Cowboy 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? design?” what Jack C. Reeves fall 1992, c++ journal
  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 “ is cheap to build. It does not qualify as inexpensive; it is so cheap it is almost free”. manufacturing == build process “ 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 “ 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 Essential EJB / Biztalk Field Level Security Accidental
  24. 24. technical ! ! ! debt
  25. 25. technical debt
  26. 26. technical debt Code Base Complexity principal effort for 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 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
  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/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/table/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ ./org/apache/struts2/components/ !
  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. “ “ 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 NEAL FORD software architect / meme wrangler ThoughtWorks This work is licensed under the Creative Commons Attribution-Share Alike 3.0 License. 3003 Summit Boulevard, Atlanta, GA 30319
  75. 75. ThoughtWorks resources Emergent Design & Evolutionary Architecture series:
  76. 76. appendix a Test-after vs. TDD Perfect Number Finder
  77. 77. appendix b Martin Fowler’s Who Needs an Architect