Consistent architecture is the cornerstone of confident testing.
Published: 2023-01-09 15:20:49

This post is about the importance of good architecture in the path to creating testable applications. Well architected applications allow a team to work quickly and confidently whilst focussing on the task in hand, rather than worrying that their changes may break existing features.
A consistent approach to UI architecture and creating features is required before you are able to get the most value, and confidence out of the tests you write.

## Quality takes ~~time~~ iterations.
Although consistency is important, it is not necessary to have the perfect UI architecture that will last forever straight away - so long as it is considered and documented, a feedback process of working and improvement can begin. Its important that any decisions have buy-in from the whole team - therefore be sure to keep everybody as involved in the process as possible - as they will be the ones giving you feedback to improve further down the line.

## The importance of framework and tooling agnostic architecture
Anyone who has worked in the industry for any length of time will be aware that the fashionable frameworks and tooling of the time change rapidly. There are use-cases where certain tooling is critical to the success of an application. These cases will be picked up during the specification stage and the temptation to add tooling should always be tempered with the question: "Can this problem be solved with a better architecture rather than tie us into a tool".

## Architectural design thinking
At the core of good design is creating something that works well without much thought. [Don't make me think](https://sensible.com/dont-make-me-think/) by Steve Krug and [The design of everyday things](https://jnd.org/about/) shows these principles in the realm of visual and product design, but the principles are universal. 

## Separation of concerns
Separation of concerns is critical in designing good software as it is universally applicable and forces you to really think about what you are doing, where and why.
Thinking should be done about the problems involved, but not about the framework itself.
Split the problem into primary concerns
Presentation concerns, Business concerns and Data concerns

## Architecture as a cornerstone
In the context of stone masonry cornerstones are the most highly engineered part of a structure. They only make us a small amount of the physical size, however they are completed by the most skilled masons. Strong cornerstones allow the other people working on the structure to build the walls between them more quickly and creatively - without risking the structural integrity of the building.
In the context of development Cornerstone architecture sets the context for the stability of the system. Once these cornerstones have been put in place, the system can be consistent. Having these constraints in place actually improves creativity as you can go any way you like - so and remain confident that the wider product will not be effected.

## The pit of success
An honourable mention goes to an article called [Falling into the Pit of Success](https://blog.codinghorror.com/falling-into-the-pit-of-success/) by Jeff Atwood. It is very relevant here as once a team has a strong architecture that they can all work within, they will fall into the pit of success and be able to work more quickly and more confidently in their roles. This breeds a feeling of confidence, self-reliance and developer-happiness which in turn will lead to a better ed product.

Although this is not a practical guide by any means, I hope that the information has inspired you to create more consistent architectural cornerstones that allow your team more flexibility and creativity as they work.
As always I appreciate feedback and this article is a never-ending work in progress, so feel free to start a discussion and we can all learn from one another.