1 / 22

Evolution of software architectures over time

Evolution of software architectures over time. Patterns, Smells, Interventions. Overview. Reasons for architectural entropy Directions: Evolution towards what? Examples / patterns Interventions Summary. Architectural Entropy Causes. New requirements “New” requirements

sydney
Download Presentation

Evolution of software architectures over time

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Evolution of software architectures over time Patterns, Smells, Interventions

  2. Overview • Reasons for architectural entropy • Directions: Evolution towards what? • Examples / patterns • Interventions • Summary

  3. Architectural Entropy Causes • New requirements • “New” requirements • “We didn’t know that at the time …” • Pyrrhic victories • Nominally met requirements, but not really. • “Uneven Developer Skills”

  4. Why is this interesting? • We need responsiveness. • Responsiveness increases or decreases over time. • Decreasing responsiveness = default.

  5. Evolution: Directions & Goals “Ingenious Complexity” “Blinding Brilliance” ??? (?) “Big Ball of Mud”

  6. People Factors • Systems reflect the personalities of their builders • Developer mindsets and “introvert discrimination” • “Teamthink” and the squeaky wheel

  7. The Role of Organizational Culture • Entrepreneurial • Idea – driven • Yearns flexibility • Institutional • Structure driven • Yearns predictability

  8. Evolved Architectures: Big Ball Of Mud • Focus • Fix it. • Motivator • “Getting it done, by hook or crook.” • Smells • Lots of bugs. • Takes a long time to make changes. • The Cult of Duct Tape (“Duct tape is like The Force….”) • “… swamp guides become more valuable than architects” http://www.laputan.org/mud/

  9. Evolved Architectures: “Ingenious Complexity” • Focus • Technology • Motivator • Technical Prowess • Smells • “Magazine Architecture” – latest technology wins • Techies talk lots of tech in business meetings • Hard to relate code to requirements • State of the art, but: • Poor usability • It takes a long time to build new functionality

  10. Evolved Architectures: “Blinding Brilliance” • Focus • SOLID principles • Motivator • Business value, usability • Smells • “Class society” among developers • Lots of friction with “old-timers” and maintainers of legacy systems • Very hard to find qualified developers (“Darth Maul Syndrome”)

  11. Example: Moving towards Anemic Domain Model

  12. Example: From Forms Over Data to Big Ball Of Mud

  13. Interventions: Simplicity EierlegendeWollmilchsau http://en.wikipedia.org/wiki/Eierlegende_Wollmilchsau

  14. Interventions: Firewalling Complexity • Recognize that not all maintainers/developers have total familiarity with the application. • A new layering paradigm (????): • “Pig” layers • Require deep commitment to understanding the system. • Experts only • “Chicken” layers: • Newbies • People in a hurry • “Pigs” on other projects, unfamiliar with this one.

  15. Interventions: Courage & Curiosity? • Facing reality • “The terrifying suchness of things.” http://en.wikipedia.org/wiki/Blind_men_and_an_elephant

  16. Evolve Towards What … ?

  17. Designing The Obvious: • Build only what’s absolutely necessary. • Quickly turn beginning users into intermediates. • Prevent errors whenever possible and handle the errors we cannot prevent gracefully. • Reduce and refine interactions and task flows until even the most complicated applications are clear and understandable. • Design to support a specific activity. • Make constant, incremental improvements to our processes and applications. • Start ignoring the demands of users and stick to a vision (gasp!)

  18. “Refactoring toward greater insight into how to make do without insight.”

  19. Conclusion • Architectures evolve towards greater or lesser responsiveness over time. • Arguably, software reflects the personalities of its makers. • Arguably, understanding people & culture makes it possible to predict what a system will look like in the future. • Arguably, interventions are possible. • Arguably, successful interventions have to be people focused and usability focused.

  20. Good Reads • “Domain Driven Design” – Eric Evans • “Working Effectively With Legacy Code” – Michael C. Feathers • “Designing The Obvious” – Robert Hoekman

  21. Q & A http://robertblogs.wordpress.com Twitter: robertreppel

More Related