Evolution of software architectures over time

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