Just A Pile of Bricks

While agile has taught us the lesson that spending large amounts of time on big up-front architecture is not necessarily productive this shouldn't discount the need for our code to have a recognisable architecture.

Architecture is what separates code from software, what separates development from engineering, and ultimately what enables continual improvement and scaleability.

So we have a fine balance to make between inefficiency caused by spending too long thinking and not doing and rushing in and making a mess.

So with this in mind how do we recognise when our code lacks an architecture? How do we know when we have a pile of bricks and not a house?

Avoidance of Thingies

The first step towards understanding what a class does should be its name, when a class is well-named looking through the source for that class should re-affirm what you assumed were going to see not shock.

The name should also imply that classes role within the overall architecture, allow certain assumptions to be made on how it is used and infer a commonality with other classes with similar names.

In code bases lacking an architecture this often isn't the case, in these code bases we have classes that share a suffix like Manager, Controller and Service that have very little in common.

Their public API's don't look the same and learning how to utilise one of them is a learning experience every time.

In a similar manner when you have to look under the hood you don't see much in common between them.

If were going to create well defined layers in our code classes that identify themselves as being part of that layer need to have commonality in approach and interface otherwise we end up with classes that may as well be called thingies.

Without this commonality we will end up with each class operating at different levels of abstraction and this imprecision will be passed out to all the classes that utilise them.

As a code base grows our understanding of how it fits together should grow not diminish, this is a Service I've used one of those before so I know what to expect, or I assume there is some kind of controller to deal with that.    

I'd Need to Look into That

A good architecture creates a narrative, you don't need to know the details of all the implementation to have an appreciation of how the system works.

This means when your asked questions like "would we able to do this?" or "what would be involved in adding this?" your able to understand and evaluate the work required and give feedback. That is not to say adding the feature is quick or easy but you understand what would need to be done.

When your working with a code base that doesn't have a clear architecture questions like this are difficult to answer and usually provoke the answer "I'd need to look at the code".

No assumptions can be made and every trawl through the source is an adventure leading to new discoveries about how things work.

When work starts on a new feature there often isn't any obvious starting point, theirs no pattern to follow or structure to fit into, everything requires an upfront brain storming session to figure stuff out.

Instead we want to be in the situation where most of the time (you can never account for everything) when were asked for something new we could list the classes or modifications that would be required because we know how things are structured even if we don't know the detail. 

Mud Pie Not A Cake

A by-product of having a clear architecture is the possibility of re-use, either within the same product or when starting a new product.

We can draw vertical lines through the code base and "lift and shift" features to slot into a different code base.

Looking at our code base is like looking at layers of a cake, clearly separated layers each with there own role to play.

When a clear architecture isn't present our cake becomes more of a mud pie, the structure isn't clear and each layer of code flows and bleeds into the other.

The possibility of re-use is greatly reduced, we can't cut vertical slices through our code because code keeps flowing through our fingers.

Ultimately an architecture needs to be flexible both to allow the code base to grow organically but also to bring the benefits of loose coupling for testability and re-use.

But even with this flexibility an architecture does need to be present and it does need to provide structure and bring all the benefits we've talked about.

This isn't an easy feet to accomplish and we'll very often get it wrong, thats why we need to recognise when an architecture is missing or is breaking down. Its easier to reverse a car than a ship, recognise when something is wrong and change it.