Your SlideShare is downloading. ×
Neal Ford Emergent Design And Evolutionary Architecture
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Neal Ford Emergent Design And Evolutionary Architecture


Published on

ThoughtWorks Luminary and Conference Presenter Extraordinaire Neal Ford will be presenting: …

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

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. ThoughtWorks emergent design & evolutionary architecture NEAL FORD software architect / meme wrangler ThoughtWorks 3003 Summit Boulevard, Atlanta, GA 30319
  • 2. index.html?S_TACT=105AGX02&S_CMP=EDU
  • 3. agenda
  • 4. things to think about
  • 5. emergent evolutionary
  • 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. spectrum of design Some DUF "Pure" Waterfall BDUF Agile Emergent Design Cowboy Hacking
  • 8. big design up front Project Planning/Estimation Requirements Use Cases/ Functional Specs Design Specifications Code Test Fix/Integrate $
  • 9. who thought this was a good idea?
  • 10. emergent (hardware) design
  • 11. finding abstractions & patterns
  • 12. Patterns nomenclature technical patterns idiomatic patterns domain patterns patterns describe effective abstractions
  • 13. abstracting too early speculation without facts YAGNI! business processes change radically and often how do you know when? experience helps spike solutions
  • 14. emergent design
  • 15. “what is software design? design?” what Jack C. Reeves fall 1992, c++ journal
  • 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. 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. 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. emergent design discovering design in code finding effective abstractions technical abstractions problem domain abstractions ability to harvest idiomatic patterns
  • 20. things that obscure emergent design
  • 21. complexity
  • 22. essential complexity inherent complexity accidental complexity all the externally imposed ways that software becomes complex essential vs. accidental complexity
  • 23. examples Hunting Season Essential EJB / Biztalk Field Level Security Accidental
  • 24. technical ! ! ! debt
  • 25. technical debt
  • 26. technical debt Code Base Complexity principal effort for new features interest
  • 27. negotiating repayment you must convince someone technical debt exists... ...start a conversation about repayment demonstration trumps discussion
  • 28. convincing metrics
  • 29. rampant genericness
  • 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. emergent design enablers
  • 32. test driven design more about design than testing design will emerge from tests atomic understanding of intent better abstractions less accidental complexity
  • 33. perfect number case study: ∑ of the factors == number (not including the number) ∑ of the factors - # == #
  • 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. 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. refactoring to harvest idiomatic patterns
  • 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. 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. 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. struts 2.x
  • 41. UIBean evaluateParams()
  • 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. fixing parameters 66 - 9 = 57 lines of obscuring duplication 22 * 3 = 66
  • 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. idiomatic “unit of work” pattern
  • 46. without closures (java)
  • 47. with closures (groovy)
  • 48. with closures (ruby)
  • 49. abstraction styles imperative structured / modular object-oriented functional anti-objects
  • 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. architecture
  • 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. application architecture describes the coarse-grained pieces that compose an application
  • 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. enterprise architecture concerns itself with how the enterprise as a whole (which usually means the applications running inside a large organization) consumes applications
  • 56. enterprise architecture == city planning
  • 57. application architecture == building plan
  • 58. extant definitions
  • 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. "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. Architecture is about the important stuff. Whatever that is. Martin Fowler’s definition
  • 62. Stuff that's hard to change later. Martin Fowler, in conversation There should be as little of that stuff as possible.
  • 63. design architecture
  • 64. architectural considerations
  • 65. politics of architecture
  • 66. build or buy
  • 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. 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. 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. 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. postlude
  • 72. design == code other artifacts aid in creating code all artifacts besides code are transient irrational artifact attachment
  • 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. 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. ThoughtWorks resources Emergent Design & Evolutionary Architecture series:
  • 76. appendix a Test-after vs. TDD Perfect Number Finder
  • 77. appendix b Martin Fowler’s Who Needs an Architect