A Tale of Two Values

Topic:

Behaviour and structure in a software system
Balancing the two, and not focusing on one to the exclusion of the other

Behaviour

Programmers are hired to make machines which make or save money for a stakeholder
We do this by writing code to a specification, as told by the stakeholder
When a machine violates the spec, we know we have a problem to fix
Implementing the spec and fixing bugs is not 100% of the job description however

Architecture

The word software can be broken up into the ware (product) and soft (referring to a behaviour)
Software is intended to be easily changeable
As a stakeholder changes their mind about a feature, the change should be simple to implement, the difficulty comes from the scope of the change and not the shape of it
Software development costs often come from a divergence between scope and shape
This is why earlier years of development on a product are far cheaper than subsequent ones
The divergence between developers and stakeholders also grows, as stakeholders believe they give changes of a similar scope, but it becomes much harder to implement them as time goes on

The Greater Value

Business managers will often prioritise a working software system over a sound architecture
Developers get forced into this way of thinking. But consider:

"If you give me a program that works perfectly but its impossible to change, then it won't work when the requirements change, and I won't be able to make it work. Therefore the program will become useless."

"If you give me a program that does not work but is easy to change, then I can make it work, and keep it working as requirements change. Therefore the program will remain continually useful. "

Eisenhower's Matrix

"I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent."

Behaviour is urgent, but not always particularly important.
Architecture is important but never particularly urgent.

The order in which we should prioritise is as follows:

Urgent and important
Not urgent and important
Urgent and not important
Not urgent and not important

The architecture of the code takes up the top two positions, whereas the behaviour occupies the first and third positions.
Software developers are hired to evaluate the importance of architecture, and express this to business managers who are not equipped to do so.

Fight for the Architecture

Effective software development teams tackle the struggle of fighting for architecture head on
As a software developer, you are also a stakeholder
Just remember: If architecture comes last, then the system will become ever more costly to develop, and eventually change will become practically impossible for part or all of the system