Three sure signs that it's time to cut your framework
In the life of almost any development team, there comes a time when creating your own framework moves from the status of “What for us to waste time?” To the status of “Cool idea!”. We had such a moment about two months ago, when we started screwing the function of voice control of transfers using Siri to PSB Mobile, PSB Mobile. We analyzed our experience and based on it we will tell you how to understand that the time for frameworks has nevertheless come.
Earlier, the bank's iOS client for individuals was developed by outsourcing. Then it was decided to rewrite everything independently from scratch. We built a process on SCRUM with two-week sprints, the work began to boil - we actively looked for and added new features, chips. At this stage of active searches it was difficult to predict what would take root, what did not. Planning everything 40 steps ahead makes no sense. Nobody thought about delights like versatility - to create your own framework, to allocate parts of the code into separate libraries for reuse. The probability that there would be no point in this was too great.
What is good SCRUM - we often contact with the business as a customer. At the same time, important changes began to occur. We began to better understand the product, business problems, business processes of the bank, in which the application participates. And most importantly, the business, for its part, began to consider the development of the application as a process, began to better understand how we work, and began to agree with us that there are important tasks whose solution does not give a noticeable momentary effect.
It helped us get together with the business ... WWDC conference. Our business customers once looked at the announcements of new apple opportunities and curiously crawled on Apple Developer. Surprisingly, everything was much clearer than expected. Since then, not only are we involved in business problems, but business is no longer afraid of technology: they try to read the specs themselves, get into the essence of the problems, help with analytics and get into development issues. They began to realize that it was useless to wait for a clear increase in the product every two weeks - there are also service sprints, from which there is no specific growth. Mutual understanding has reached the point that we have agreed to give refactoring 20% of the time to sprint.
With the growth of the development department, filling the application with all new features, the appearance of several teams working in parallel on different tasks, new nuances began to appear. Some subtasks of the teams could be similar, and immediately there was a desire not to reinvent the wheel, and the first thing to clarify is whether someone already has a ready-made code.
There are usually no complaints about the code from our developers, so it is quite possible to use it again - and not only within the framework of the usual code reuse methodology. Probably, already at this stage, the idea arose in our heads to allocate some things into separate libraries for general benefit. But within the framework of existing tasks, it was not possible to find time for these processes. Some excuse was needed, and soon the business threw it at us.
There was a task to make voice interface support - so that through Siri it was possible to make payments to other bank customers by phone number. He says: "Transfer so much money to such a person." And if this person is Promsvyazbank's client, then a person’s card appears on the screen, the amount of the transfer, the question “send money?” And the “Send” button. A similar function is already in some banking applications, but we wanted to make it so that, on the one hand, it was safe, and on the other, the client did not need to go into the bank application.
Working with Siri means writing a separate extension, and when we began to plan it, we realized that it was time to develop our own frameworks. In our application project, the network layer was implemented, and there was a choice (actually not): write this layer anew or take it into a separate container, accessible both in the main application and in a separate extension.
In the process of work, an architectural subtask emerged to render a part of the code into separate frameworks. There are four of them:
It is clear that this is not our know-how. So it is customary to do in such situations, this is best practice of all self-respecting developers. But it is important how we came to this. It was at this point that the three key features for creating the framework came together :
After awareness, everything turned out to be easy. At the next meeting of developers, we discussed the details, chose thevictim of the responsible person, who will do the main refactoring, gave him time - full time for this task. The rest of the developers it almost did not touch. But when we started to bring the network layer into the framework, we immediately came up with ideas on which other frequently used parts of the code should be brought to the library. Our architectural possibilities suddenly expanded. We began life with an extra degree of freedom.
But we use it without fanaticism. To decide whether to make the code in a separate module or not, we look at backlogs, determine whether this module will be reused, in several places. If not, then you should not bother.
Do we see the benefits of using our frameworks? Definitely yes. Now we see what parts of the code required under the new task are already in the repository. The development of new services is faster, there are fewer errors in programming, the quality of final services is higher.
If you need new extensions for iOS, we already have the necessary frameworks, you can immediately experiment. As for the already implemented service with Siri, it has been available to bank users for more than a month - now we collect reviews, including to understand how and for what else to use the voice interface.
The story of Siri made us think not only about the frameworks, but also about the interfaces in general. Humanity has not yet learned how to measure concentration, only indirectly. For example, the worse the UX and UI, the more attention is spent, the more the conversion funnel narrows with each step. Regular money transfer through the bank's application requires the user to heap actions: open the application, log in, search in one list, in the second, enter the addressee. With Siri, this is unlocking plus voice command. Authorization occurs in the foreground through Face ID. And in some scenarios you do not even need to bring the phone to yourself. For example, when you are driving and the phone is attached nearby, the camera can easily identify you.
Look around: voice assistants are beginning to actively conquer the surrounding space. The excitement around a smart speaker from Yandex, washing machines that speak and understand orders, TV remotes that recognize voice. The more users will be surrounded by voice interfaces, the more they will be ready to communicate with banking applications.
Graphic interfaces in this situation will lose their monopoly, they will turn from the main means of communication simply into a visual confirmation of the action, into a way to signal that the computer has understood you correctly.
For the developer, such a change, in principle, is not scary. With the right architecture, an application can have as many interfaces as possible: visual, voice, neuro. The main thing is to use approaches that correspond to the current level of maturity of the team.
“What kind of framework are you talking about?”
Earlier, the bank's iOS client for individuals was developed by outsourcing. Then it was decided to rewrite everything independently from scratch. We built a process on SCRUM with two-week sprints, the work began to boil - we actively looked for and added new features, chips. At this stage of active searches it was difficult to predict what would take root, what did not. Planning everything 40 steps ahead makes no sense. Nobody thought about delights like versatility - to create your own framework, to allocate parts of the code into separate libraries for reuse. The probability that there would be no point in this was too great.
WWDC has tied us up
What is good SCRUM - we often contact with the business as a customer. At the same time, important changes began to occur. We began to better understand the product, business problems, business processes of the bank, in which the application participates. And most importantly, the business, for its part, began to consider the development of the application as a process, began to better understand how we work, and began to agree with us that there are important tasks whose solution does not give a noticeable momentary effect.
It helped us get together with the business ... WWDC conference. Our business customers once looked at the announcements of new apple opportunities and curiously crawled on Apple Developer. Surprisingly, everything was much clearer than expected. Since then, not only are we involved in business problems, but business is no longer afraid of technology: they try to read the specs themselves, get into the essence of the problems, help with analytics and get into development issues. They began to realize that it was useless to wait for a clear increase in the product every two weeks - there are also service sprints, from which there is no specific growth. Mutual understanding has reached the point that we have agreed to give refactoring 20% of the time to sprint.
Evolution of bicycles
With the growth of the development department, filling the application with all new features, the appearance of several teams working in parallel on different tasks, new nuances began to appear. Some subtasks of the teams could be similar, and immediately there was a desire not to reinvent the wheel, and the first thing to clarify is whether someone already has a ready-made code.
There are usually no complaints about the code from our developers, so it is quite possible to use it again - and not only within the framework of the usual code reuse methodology. Probably, already at this stage, the idea arose in our heads to allocate some things into separate libraries for general benefit. But within the framework of existing tasks, it was not possible to find time for these processes. Some excuse was needed, and soon the business threw it at us.
Trigger Extensions
There was a task to make voice interface support - so that through Siri it was possible to make payments to other bank customers by phone number. He says: "Transfer so much money to such a person." And if this person is Promsvyazbank's client, then a person’s card appears on the screen, the amount of the transfer, the question “send money?” And the “Send” button. A similar function is already in some banking applications, but we wanted to make it so that, on the one hand, it was safe, and on the other, the client did not need to go into the bank application.
Working with Siri means writing a separate extension, and when we began to plan it, we realized that it was time to develop our own frameworks. In our application project, the network layer was implemented, and there was a choice (actually not): write this layer anew or take it into a separate container, accessible both in the main application and in a separate extension.
In the process of work, an architectural subtask emerged to render a part of the code into separate frameworks. There are four of them:
- Network (middle) layer - here all the work with the network, model classes, API services. This layer is fully automatically generated.
- Authorization
- Utilities - service utilities and helpers
- Storage - Secure Storage
It is clear that this is not our know-how. So it is customary to do in such situations, this is best practice of all self-respecting developers. But it is important how we came to this. It was at this point that the three key features for creating the framework came together :
- We have built enough code base
- Businesses began to understand our (i.e., their) architectural needs
- There was a suitable task
New Horizons
After awareness, everything turned out to be easy. At the next meeting of developers, we discussed the details, chose the
But we use it without fanaticism. To decide whether to make the code in a separate module or not, we look at backlogs, determine whether this module will be reused, in several places. If not, then you should not bother.
Do we see the benefits of using our frameworks? Definitely yes. Now we see what parts of the code required under the new task are already in the repository. The development of new services is faster, there are fewer errors in programming, the quality of final services is higher.
If you need new extensions for iOS, we already have the necessary frameworks, you can immediately experiment. As for the already implemented service with Siri, it has been available to bank users for more than a month - now we collect reviews, including to understand how and for what else to use the voice interface.
Some futurology
The story of Siri made us think not only about the frameworks, but also about the interfaces in general. Humanity has not yet learned how to measure concentration, only indirectly. For example, the worse the UX and UI, the more attention is spent, the more the conversion funnel narrows with each step. Regular money transfer through the bank's application requires the user to heap actions: open the application, log in, search in one list, in the second, enter the addressee. With Siri, this is unlocking plus voice command. Authorization occurs in the foreground through Face ID. And in some scenarios you do not even need to bring the phone to yourself. For example, when you are driving and the phone is attached nearby, the camera can easily identify you.
Look around: voice assistants are beginning to actively conquer the surrounding space. The excitement around a smart speaker from Yandex, washing machines that speak and understand orders, TV remotes that recognize voice. The more users will be surrounded by voice interfaces, the more they will be ready to communicate with banking applications.
Graphic interfaces in this situation will lose their monopoly, they will turn from the main means of communication simply into a visual confirmation of the action, into a way to signal that the computer has understood you correctly.
For the developer, such a change, in principle, is not scary. With the right architecture, an application can have as many interfaces as possible: visual, voice, neuro. The main thing is to use approaches that correspond to the current level of maturity of the team.