In Software, You Build To Change Too

There are moments when differently considering how a domain is captured and expressed leads to an epiphany of sort: A much clearer insight into the matter at hand.

It could be a slight or simple change of point of consideration, but the insight it leads to, could be quite profound.

The Earth moved. A simple change in the way the solar system is viewed but a change that led to a significant upheaval of not just how we understand the cosmos; but a change that also rattled the political and power structures at that time.

I recently had a similar change with regards to how I internally conceptualize Software Development (or construction) and Software Architecture. Not surprisingly, my internal modelling has largely been shaped by the type of architecture that I am most exposed to: which is the civil type: how buildings are made, roads, bridges etc. And in these domains, the primary concern is building to last. The success of the architecture of a bridge is judged on how long it can last without fail. Same goes for high rise buildings. Building to change is not primary in these domain. 

This view has been projected onto how I primarily perceive Software Architecture. A great Software Architecture is the one that creates software that can always keep performing no matter what. This is the building to last metaphor.

But just as building to last applies to software; building to change is (should) also be core too. In fact; how well a software facilitate easy change would determine how long it may last.

Software is meant to mutate, by its very nature, with time. And a good software architecture is one that enables for easy change to the system while ensuring the system continues to provides its utility.

So when approaching a software creation process; keep in mind that building to change is as much important as building to last and let this fashion the architectural decisions you make.