evolution of software architectures over time
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
Evolution of software architectures over
timePatterns, Smells, Interventions
Reasons for architectural entropy Directions: Evolution towards what? Examples / patterns Interventions Summary
Overview
New requirements “New” requirements
◦ “We didn’t know that at the time …” Pyrrhic victories
◦ Nominally met requirements, but not really. “Uneven Developer Skills”
Architectural Entropy Causes
We need responsiveness. Responsiveness increases or decreases over
time. Decreasing responsiveness = default.
Why is this interesting?
Evolution: Directions & Goals
“Big Ball of Mud”
“Ingenious Complexity”
“Blinding Brilliance” ???
(?)
Systems reflect the personalities of their builders
Developer mindsets and “introvert discrimination”
“Teamthink” and the squeaky wheel
People Factors
Entrepreneurial◦ Idea – driven◦ Yearns flexibility
Institutional◦ Structure driven◦ Yearns predictability
The Role of Organizational Culture
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/
Evolved Architectures: Big Ball Of Mud
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
Evolved Architectures: “Ingenious Complexity”
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”)
Evolved Architectures: “Blinding Brilliance”
Example: Moving towards Anemic Domain Model
Example: From Forms Over Data to Big Ball Of Mud
Interventions: Simplicity
Eierlegende Wollmilchsauhttp://en.wikipedia.org/wiki/Eierlegende_Wollmilchsau
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.
Interventions: Firewalling Complexity
Facing reality “The terrifying suchness of things.”
Interventions: Courage & Curiosity?
http://en.wikipedia.org/wiki/Blind_men_and_an_elephant
Evolve Towards What … ?
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!)
Designing The Obvious:
“Refactoring toward greater insight into how
to make do without insight.”
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.
Conclusion
“Domain Driven Design” – Eric Evans “Working Effectively With Legacy Code” –
Michael C. Feathers “Designing The Obvious” – Robert Hoekman
Good Reads
http://robertblogs.wordpress.com
Q & A
Twitter: robertreppel