2: A Tale of Two Values

Software systems provide two different values to stakeholders: Behavior & Structure
Developers are responsible for ensuring both values remain high.
Unfortunately, they often focus on one at the exclusion of the other.
They often focus on the lesser of the two: Behavior.

Behavior

Many developers believe it is the entirety of their job to make the machine implement the requirements and fix bugs.
They are sorely mistaken.

Architecture

Software must be soft (easy to change).
When stakeholders change their mind, that change must be easy to make.
Developers often feel as if they are forced to jam square pegs into round holes.
The problem/reason, is the architecture of the system.
Architectures should be as shape agnostic as possible.

The Greater Value

Is it more important for the software to work? or be easy to change?
- Management: Often favors functional behavior.
- Developers: Often go along with management.
- This is the wrong mindset
A program that works but is difficult or impossible to change won't work when the requirements change. Systems that are difficult or impossible to change occur when the cost of the change exceeds the benefit of the change.
A program that does NOT work but is easy to change can be made to work and keep working when requirements inevitably change.

💪 Fight for the Architecture

It's always a struggle!

Role: The Team

The dev team must struggle for what they believe is best for the company.
Effective dev teams tackle the struggle head on.

Role: Developers

You are a stakeholder too!
You have a stake in the software you need to safeguard.
Unabashedly squabble with other stakeholders as equals.
This is your role, duty, and the reason you were hired.

Role: Architects

This challenge is doubly important.
Requires more focus on the structure of the system than its features and functions.
Create an architecture that allows features & functions to be easily developed, modified, and extended.

If Architecture comes last...

The system will come more costly to develop
Change will eventually become impractical
The team did not fight hard enough for what they knew was necessary

Previous1: Design & Architecture Next3: Paradigm Overview

Last updated 11 months ago

The Greater Value

Is it more important for the software to work? or be easy to change?

Management: Often favors functional behavior.
Developers: Often go along with management.
This is the wrong mindset

A program that works but is difficult or impossible to change won't work when the requirements change. Systems that are difficult or impossible to change occur when the cost of the change exceeds the benefit of the change.

A program that does NOT work but is easy to change can be made to work and keep working when requirements inevitably change.

💪 Fight for the Architecture

It's always a struggle!

Role: The Team

The dev team must struggle for what they believe is best for the company.

Effective dev teams tackle the struggle head on.

Role: Developers

You are a stakeholder too!

You have a stake in the software you need to safeguard.

Unabashedly squabble with other stakeholders as equals.

This is your role, duty, and the reason you were hired.

Role: Architects

This challenge is doubly important.

Requires more focus on the structure of the system than its features and functions.

Create an architecture that allows features & functions to be easily developed, modified, and extended.

If Architecture comes last...

The system will come more costly to develop

Change will eventually become impractical

The team did not fight hard enough for what they knew was necessary