Agile Architecture

In many agile teams the role of architecture is derided and on occasion actively avoided.

I think this view point comes from mistakenly equating architecture with planning.

As agile teams we don't won't to get bogged down in planning and we don't require a large upfront design to get started in delivering value.

And thats fine because this isn't the role of architecture.

Architecture isn't about exactly how we might implement a possible new feature six months down the line, it should be about how we make sure our code base is built to accept change and adapt so that if that feature does come further down the line we haven't painted ourselves into a corner.

Agile teams will often describe their architecture as emergent, I think this can be dangerous if you expect a robust architecture to just come riding into view when you've paid it no thought, instead I believe we should be aiming for an emergent codebase that can go anywhere we want to take it.

Two Big Questions

I don't believe its anti-agile to take a small amount of time just thinking through the structure of the code were about to write, this thinking should be aiming to answer two questions,

How will we test this?

How would we change this?

Agile architecture should be about being able to scale, we need to be able to adapt to new requirements quickly and we need to be able to verify our code still works.

This means the two most important properties our code can have is testability and adaptability, being able to fall back on these two things means you will never be fearful of a new requirement. 

Failing to think about these two things means the architecture that emerges will be brittle and ultimately will fall apart.

Look After the Small Things

Although having this scaleability in our code base is a long term aim fortunately we can ensure we get there by taking care of the small things in the here and now.

SOLID is all about taking care of testability and adaptability, ensuring you write your code being guided by these principles whilst taking a small amount of time to think through how you want to structure things will allow for the emergence that were seeking.

Always Ready to Go

Once we have the emergent code base that will allow us to grow another important aspect of our architecture needs to be the ability to deliver at a moments notice.

For this to be a reality we need to embrace automation, in building, in testing, and deploying, the architecture of our build processes is just as important as the architecture of our code.

If we prefer working software over documentation then we need to ensure that as little energy as possible is expended in getting that working software though the door.

Shaping the Future

Software provides solutions to problems, the genesis for wanting to reduce the role of architecture within an agile team comes from our propensity to solve problems that don't exist yet or becoming too obsessed with minor details.

The role of architecture should be to create a framework to allow creativity, to enable solutions to be found and implemented when the need arises.

Good architecture stops us creating a straight jacket that suffocates us from being able to move forward.

Without this flexibility it is impossible to be agile, without a bias towards automation it is impossible to be agile.

The concept of MVP should be applied as much to architecture as it is to the product the architecture needs to deliver.

We need to define the simplest architecture that can possibly work and continue to work in the future when we change exactly what working means.   

Test Driven Benefits

I've written many times about the virtues of unit testing, first and foremost because its the best way to prove that code works as expected.

But as with many aspects of good development practices if you do the right thing you'll profit from many additional benefits.

This is also true with unit testing, its the right thing to do, and as well as verifying your code is fit for purpose it can be the mechanism for other good things to happen.

Consumers First

Code is written to be consumed by others, and the very first consumer is your unit tests. Its your chance to both document how your API is intended to be used as well as place yourself in the position of being a user of your code rather than the producer.

Unit tests can be used a design tool, as your writing your tests always be assessing does this make sense, pay attention to things like how much set-up and tear down is needed, does this represent state that will not be obvious to someone trying to utilise this class?

Unit tests are very good documentation, they not only demonstrate the code being used they also state expectations on the data that should be fed in and the data that will be fed out. 

Shrinking the Circle

Every developer has been on the treadmill of making a change to some code, deploying that code, interacting with that application, finding that bug is still their and back round to the start.

This is dull and inefficient, it might be several minutes before any modification can be verified and on a tricky pest of a defect might be a cycle that is repeated all day.

Unit tests are a very good debug tool, a bug in a class that manifests itself in your application should also be visible in your unit tests, if its not you need to write more tests.

Using your unit tests to find a problem will give you much quicker feedback on the impact your changes are making, if the tests are well written it also helps isolate the code that may be causing the issue, your able to ask more precise questions, does this class do the right thing in this situation?  

The What-Ifs

The infrastructure in your unit tests that ensures your mocking dependencies and decoupling your classes reveals your architecture, whether good or bad.

There is a lot of knowledge to be gained by looking at what tests break if you make a change, if we make this change a lot of tests in many different areas of the code base break, why is that and does that indicate we need to make a change?

It also allows you to speak with confidence if your asked a what-if question, we're thinking of adding this feature or making this change, the scale of that work will often be linked to level of decimation it will cause in your unit tests.

Following principles like single responsibility and open-close should ensure that changes don't cause carnage in your unit tests, you'll always be adding more unit tests but are you constantly having to re-write the ones you already have?

Hopefully everyone is realising the benefits of automated testing, and if the only benefit your drawing from it is the automatic verification that your code still works then its been worth it but be open to the fact that there is a long list of other benefits to be plundered.

This is just one example that if you do the right things good code will happen and you'll expunge less energy and brain power in producing it.