Bob Martin coined beautifully in his book “Clean Architecture” that software – the products we forge from our imaginations to deliver value to other humans – can be described as a combination of behaviour and structure.
This is what the product does; ultimately it does something beneficial for a human somewhere, even if this is several times removed. It’s features, the benefits those features deliver.
Behaviour of the product delivers the value to the customer and therefore the business owners, and is quite rightly the main focus of software development.
The products shape, or its architecture. How the components; methods, classes, assemblies and services are inter-related. The mapping of responsibilities to deliver the functional components that combine to deliver the desired behaviour.
Every product has structure – very few have a “good” structure. Good structure allows rapid change with minimal cost, championing leaving options open and decisions late (more on this later).
Structure is often thought of and presented as flow charts in 2 dimensions. However, in most cases a products structure is actually a multi-layered 3 dimensional affair, very difficult to actually envision, to share and to design. This challenge to communicate structure and it’s importance (value) often means it falls to secondary “nice to have” objective.
In the short term, structure (architecture) appears to slow down software development. An apparent pointless activity adding effort and $$ onto a usually time constrained development process.
Behaviour over Structure
Commercial enterprises need revenue to keep the lights on. That means customer value is king; and for a start-up they need to return as much value as quickly as possible. The pressure to deliver function is extreme.
The sprint to sprint focus is customer value results, with many teams being pressurised to deliver function (behaviour) over architecture (structure). For many start-ups without technology at their core, these initial developers will also be contractors embedded with short-termism. They want their month to month contracts renewed, so they need to focus on delivering what the business wants, not what they need. In addition my experience is many developers (even Computer Science qualified) do not understand the concept or importance of architecture (structure) in software development.
This leads us to an industry full of products that have poor architecture. They cannot change – cannot evolve as the customer, the market and teams surely will.
Many times I’ve come to brown field products which were a hideous, convoluted mess. Change is very difficult or impossible to deliver. What’s probably worse is the business owners had no awareness that they owned a train wreck, completely unable to change until it’s too late.
Structure over Behaviour
Is it more important to have a product that does what the customer wants, but can’t change? Or a product which does not do what the customer wants, but can change rapidly?
That’s the question we’re asking when we are seeking to understand which we prioritise; structure or behaviour.
Last year I read Simon Sinek’s amazing book “The Infinite Game“, which I highly recommend. It inspired me in my technical leadership – and I think we have a lot to learn from his thoughts in the software industry.
As software developers we should create and maintain products which are designed with an “infinite” mindset.
To develop systems which are designed to be alive, maintained and competitive decades into the future.
Structure is the first and continuously the most important aspect of a software system. We should be focusing on the product being able to evolve and change with the minimum of cost, maximising ROI of the value being delivered to the customer (or user).
I’m going to be posting more blog posts on this expansive subject. Whether you’re a business owner or a software developer, stick around to see how critical an “infinite architecture” mindset is to a successful technology company.