Applications are ubiquitous. People use mobile applications every day, even they are not installing it on the phone. The development of any piece of software requires a lot of resources, man-hours, coffee, and meetings.
Reliability, scalability, and maintainability are ways to secure your investments into the development counting each dollar spent. But how the architecture of the application and well-designed code differs from conversion, marketing or any product development? These factors influence a speed of development, fast iterations, and validations of features and prototypes and thus, directly improve conversion and e-commerce metrics.
In case of the app development, there can be a situation when stakeholders think about the app working on a handheld device as a small thing. And sometimes the support of application or maintainability is not considered as an aspect of requirements and implementation.
What is mobile applications scalability and maintainability? I see it in two dimensions: a scale of the app usage by handling any possible number of users, events, client-backend services, and scale in the development (maintainability) by allowing developer deliver fast and robust features with minimum interaction with the legacy code.
The scalability of the app refers to handling any number of connections from user side, backend API interaction, error-handling. The maintainability is a way to iterate on software product by adding a new feature of fixing bugs in an efficient way.
One of the definitions of legacy as the code is any code which was written in the past even a minute ago. The scalable approach or architecture ideally allows adding a new feature and changing existing ones with minimum efforts.
In my experience, all projects where maintainability and architecture were first-class citizens the changes to the codebase and adding a feature were the seamless process because the legacy was a minimum part and extensibility was a goal.
Note: there are many types of architectures, the present ones are working, the new ones will be better but every approach is suitable as long as it gives a room for scaling and maintainability.
The point of architecture is the definition of scalability in all stages of development whether it is a kickstart or support.
The code is an investment and it is supposed to make a profit or be useful for non-profits needs. So knowledge of architectures is beneficial from the Return on investment side and the ability to extend, support, and modify is the key for successful software product.
The ability to iterate quickly on the product development is key part of the return of investments. By making an extensible architecture gives a way to produce product and receive feedback instantly.
So how we invest in architecture? Is there any way to secure our code for extensibility?
The first step is architecture becoming a contract between developers. No matter what architecture VIPER, MVC, MVVM since most developers of a project are working in the same coding architecture.
The example of maintainability lies in the basics of software architecture. One of the SOLID rules is Open/Close principle states:
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
One example is the CLEAN architecture for Android which gives basic rules of separation of responsibilities and boundaries for each level. Having boundaries and clear responsibilities among classes is always beneficial for scaling. It is widely used in Android development although I believe it is highly applicable to any other platform such iOS.
The example of CLEAN architecture:
Presentation layer: model view, presenters, controllers
UI layer: views
DB layer: repository or data access objects
Domain layer: use cases, business logic
An example of “clean” architecture is VIPER for iOS application. As stated from the acronym:
V: View layers that defines a user interface.
I: Interactor or Domain layer: use cases, business logic.
P: Presenter prepares views and processes user input or events. The analog: presentation layer or ModelView.
E: Entity. The same as CLEAN, it is the data layer
R: Routing manages navigation logic in the app.
The reader can notice the very similar structure in layers of iOS and Android modules. They come from using the same Clean architecture patterns.
The architectures or the app modular structure can evolve as well with ongoing changes as changing DB layer from one pattern to another. And it is a natural way of iteration for refactoring. The persistence layer can have Data Access Object pattern changed to the Repository. In my opinion, it would be beneficial to the project when a product owner would participate in this type of change, no matter if it is technical or commercial one. The architecture is still a part of a product.
The key issue is opinions of roles and neglect of the maintainability from the management and product side. In some situations, the management wants a quick minimum viable product then realizing that extension takes a place. And some development fails but not being able to iterate fast.
The agile development starts with iteration and adapting to requirements and feedback from a customer or users from one hand, and being able to iterate with a given codebase from another.
Here comes some math. We can define a feature of the product as b - time needed for feature development, the sprint as a set of features Σ b, where a ( a ≥ 1) is a complexity factor, t ( t ≥ 0 ) is time for adjusting feature to the architecture, with next formulae:
Using defined architecture with defined module structure helps to reduce a time for adjusting architecture to zero and set the complexity to the minimum. If we consider the most optimal variant where the architecture is well defined we have the next simplified definition:
So knowing how to iterate on a project adding modules with a minimum change of architecture helps to understand the development time and improve life in a planning perspective.
The conclusion here is simple. A team who want to iterate fast can use one bespoken architecture and use it until stakeholders feel it is enough for quick iterations. To simplify, each iteration has the number of features per sprint in the agile environment. When a team sticks to the architecture which fits current needs and gives enough room for iteration the process becomes easier.
