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.  

What Does Anti-Agile Mean?

The majority, if not all, of the people reading this will be working in agile teams. That will mean different things in different organisations but that isn't necessarily a problem.

Agile isn't one size fits all, a drastic over simplification of agile might be "try things, do what works".

But when does something become anti-agile? When does it actually stop us from achieving our goals?

Interrupting the Flow

An important aspect of agile is effective and on-going communication, with the most valuable form of which being face to face.

Something is anti-agile if it gets in the way of people just talking and figuring stuff out.

This can come in many forms, poor division of work and resources causing constant blockages by being reliant on others who are siloed with there own problems.

By having a needless hierarchy creating ineffective lines of communication where the people who can work through problems are communicating via proxies.

An agile mentality assumes that if smart people are given the time and room to work with each other they will produce results, this process cannot be forced or controlled it just requires trust.

Build Something

Some other processes place a large importance on having a plan, its a misconception of agile that it doesn't involve a plan.

Agile does involve a plan, the difference is the scope, we don't plan to take over the world we just plan to make a start towards doing it. We realise that users can't use plans but they can use the things we build.

Anything that gets in the way of building something is anti-agile. This is nearly always caused by a fear of the unknown, how do we know this is the right answer?

The truth we have to swallow is your never going to know in advance that your doing the right thing, you cannot plan to succeed you can only plan to have your best stab at it.

Users tell you if you doing the right thing and they do that based on the product you put into their hands not based on the plan of what you intend to one day give them.

Listen Don't Tell

In a similar vain your best chance of succeeding is when you listen to what people want.

Users will tell you what they want, users aren't always right and sometimes you will need to persuade them that your idea is a good one but you won't be able to do that effectively and you want be able to adapt if you don't understand where your users are coming from.

Developers will tell you how they can best work effectively, they are the ones who have to make your vision a reality, if you don't trust them to know how to do that you've put together the wrong team, you need to succeed because of your team not in spite of them.

Its anti-agile to assume you have all the answers, an agile team will embrace their ignorance and see it as an opportunity to learn, to find out what people want and deliver it.

Flex Don't Snap

The theme running through these points is the need to be flexible, with agile the clue is in the name.

Questions can be hard to define, answers can be wrong, people can make mistakes. You can either spend a long time following a clearly defined plan moving slowly towards failure or you can accept the fact that there will be rough seas that require changes in direction.

Something is anti-agile if it prevents you from implementing change when you know its the right thing to do.

It sounds crazy to think that a team could know they are doing the wrong thing but carry on anyway, but it happens all the time when that team is operating in an environment that isn't agile.

Either the people that know this is wrong aren't communicating, your not finding out from the user if they want what your doing or your machine is so big that it simply cannot change direction.

You can't be told how your team can work in an agile manner, you have to figure that out for yourself, but there are guidelines you can follow.

You'll find your own way you just need to be able to recognise when your heading in an anti-agile direction and hit reverse. 

Playing Strong and Loose

There are four important concepts in development, sometimes they get mixed up but its important to have a good understanding of the relationship between them.

"Abstraction leads to loose coupling"

"Encapsulation leads to strong cohesion"

So why exactly are these statements so important are why do we sometimes get them confused?

Abstracting Away the Detail

The purpose of abstraction is to hide detail.

Detail leads to complexity, complexity leads to instability and instability leads to unhappy users.

Whenever we define how pieces of code are going to interact this should be based on an abstraction that represents the functionality that is going to be consumed, it shouldn't be based on details of how that functionality will be implemented.

As a slightly contrived example, if you wanted to save files you wouldn't expect the interface to do so to talk in terms of disk sectors and binary sequences. You might instead expect to use file and file-writer abstractions to protect you from that complication.

Once your protected from the detail then the implementation can be tweaked, modified or completely rewritten without your code breaking, this is what we mean by loose coupling.

Coupling is a mechanism by which classes are connected to each other and can act as a channel for all sorts of things to be transmitted between them including complexity, defects and breaking changes.

Encapsulate the Concept

A class in your code should represent something in your problem domain, anyone that understands that domain should recognise what the class represents and realise how it can be used.

When this isn't the case and a class only loosely represents a concept developers will end up having head scratching moments where they have to write code where it isn't immediately obvious either why some invisible join between classes has to be made or why a certain piece of functionality lies in a particular place.

Classes that do properly represent a concept are said to have strong cohesion, every line of code in them is all geared towards representing the same concept.

Cohesion is a mechanism by which understanding can be transmitted to a developer looking at your code leading to less head scratching and more productive time building well engineered solutions.

Strong and Loose

Sometime these concepts can get mixed up in developers minds, this isn't surprising since they very often interrelate, a class that operates at a good level of abstraction often also demonstrates good encapsulation.

A good abstraction hides the detail of the implementation by being well focused on representing a single concept within the system which brings us back to encapsulation.

The important thing to remember is that its all about the relationship between code, code inside a class should be very closely related whereas the code between classes should be very loosely related.

If code represents detail this means detail in one class shouldn't relate to or depend on detail in another class, if it does its because an inadequate level of abstraction is failing to hide detail or because bad encapsulation means code that should be together has been split-up.

Spotting which once of these is causing the problem is not always easy and in many ways is the essence of what it means to be an experienced developer but remembering that all these things are interrelated and that detail, complexity and confusion are the enemy is a pretty good start.   

The Scores on the Board

As developers working within an agile team we spend a significant amount of time looking at some kind of sprint board.

We see what's left to do, whats being worked on and what we've completed. All of this helps us tell whether or not were going to achieve our goals.

But is their actually more to see on the board than that? Is it actually possible that the board can tell us something about our code?

Stories Reflect The Code

I'm sure all of us have been in the position where were struggling to see a way through the sprint.

"This story depends on that one, and we can't start that until this one is done" 

Quite often were quick to just write this off as bad luck or bad planning but when this happens over and over again is their something more?

Tightly coupled code will produce tightly coupled stories. If you struggle to break down your code base into elements that can be worked on individually and simultaneously all of your sprints will contain a lot of blocked stories, progress will be slow and much of your resource will be twiddling its thumbs.

This will never be more true then when your sprint involves making changes to an existing part of your system, the extra time taken early on in development to define some robust and flexible interfaces will be paid back here when you can fully utilise everyone in the team can get stuck into making the necessary changes.

This isn't just about the developers either, sprints with a lot of blocking stories will also be hard on testers as it inevitably results in a big bang of delivery to test towards the end of the sprint rather than a gradual stream.

How Many Points?

Even before the sprint starts the quality of our code can influence how smooth the agile process will be.

A major part of pre-sprint activity is pointing the stories which can on occasion be greeted by a large exhaling and puffing of checks from everyone involved.

An inability to point a story can be caused by the story not being well defined or ambiguous but it can equally be caused by the code.

It isn't easy to point stories when the code is large and complex and where the interaction between classes or sub-systems is strongly coupled in a manner that is not easy to penetrate.

In this situation their is also a tendency to be pessimistic adding on a certain margin because were confident things are going to go wrong when we start trying to work with that part of the code base.

This ball of string pointing where we become scared that if we change this everything else is going to come crashing down around us is another sign that the agile process is giving us just as much information about our code then it is about our product and team.

We Still Have Defects

Defects are a fact of life in software development, the business of writing code is too complex for mistakes never to be made and for consequences to always be anticipated.

But this doesn't mean that we should just shrug our shoulders whenever a defect is found. This isn't to say that we should be looking for someone to blame but more that we should be identifying why this particular change to this part of the code is causing so many problems.

This is not only to help understand how we can improve the code base but also to stop fear spreading. A strong desire to not change one particular aspect of the code can lead to bad decisions being made, decisions that from a structural or architectural view don't make sense but simply mean if we do it like this we don't have to touch that.

As with most things in life it best to take your medicine early, if you start seeing signs that something is wrong, no matter where those signs may be coming from take the information on board and plan a remedy.

Agile is indeed the gift that keeps on giving, it not only allows us to effectively streamline and manage our delivery but also gives a lot of feedback on the quality of our code all we have to do is listen.