How to approach the creation of a complex product: 3 tips for developers

For many years we, at Latera, have been developing billing for telecom operators and are developing a service for managing Planado employees.

Billing is a complex product, work on which has its own characteristics. Firstly, it is a highly specialized enterprise-level tool that is implemented by hundreds of copies, and not by tens and hundreds of thousands. Secondly, the system should operate in 24x7x365 mode. And the most important thing is that billing counts money, which means it is a critical element of the infrastructure of any company.
')
In our previous articles we talked about how to organize technical support for such a system and why it is better to entrust its implementation to professionals . Today we will discuss the approaches that should be applied in the development process.

Immediately think about future improvements.

Software is always intended to solve the problems of a specific subject area - in our case, these are billing operations. In this case, the task formulated by the customer at an early stage is often incomplete and does not take into account all the difficulties that may arise in the process of creating and using the product. In this case, it will be difficult to avoid problems.

Illustration from the sphere of telecommunications close to us - different operators require different billing capabilities. The features of the telecom industry can be in different regions - for example, there are no wired communication channels in Norilsk and Magadan, only a satellite is available. Therefore, Internet access is very expensive and tariffs with traffic quotas are still running. The same situation is in some countries of Central Asia (for example, Afghanistan) and Africa (Nigeria).

The size of the subscriber base may also be important - the processes of a small and federal provider are built differently.

All this means that it is impossible to create a system that would satisfy all possible “wishes” of customers. But you can predict directions in which future users may want to refine the product.

If this is done at the design stage, you will avoid many problems. At the same time, it is not at all necessary to realize all the possibilities inherent in the architecture - it is important that later they can be introduced with little blood and without crutches.

The main secret of how to avoid such errors is simple - you need to seriously analyze the subject area before taking any action. For example, if we need any major improvements, we spend up to 20% of our time in communicating with clients, immersing ourselves in their business task, studying common practices and developing requirements for functionality. If, however, limit the refinement only to those that need a specific customer, for others it will be useless. And for a serial software product, this is a guaranteed loss.

Do not try to grasp the immensity

Trying to predict future product refinements is a good thing, but this approach faces challenges. Unreasonable expansion of the domain model leads to cumbersome technical solutions, which are then expensive to maintain, and it will be difficult for customers to use them.

According to our observations, many of the wishes of users — even very popular ones — can in fact be dictated not by the subject area for which the product is created, but by their previous experience. For example, many people first try to write the billing themselves, and then, realizing the viciousness of this approach , they want to switch to a serial solution.

The problem here is that during the work with the samopisnaya system - and these are usually years - the employees of the company and its managers get used to non-optimal solutions. And then they want to see the same “crutches” in the new product. Implementing them means destroying the system architecture, making it less stable and complicating support and implementation.

For example, many customers asked us to automate the process of connecting a new subscriber in the billing. They got used to it, there were a lot of applications, and we went with them. One year later, we realized that we were wrong: the functionality turned out to be too limited, and the written code complicated the solution of billing tasks. Having studied the subject area, we came to the correct decision, rendered the processing of applications into a separate product and made it open source.

So listening to customers is important and important. However, you need to critically approach their ideas and not be afraid to make some features on the forbidden list. And then - refuse to customers who will be asked to implement them. It will be much more useful to see their true problems, which always grow out of business, to study the experience of colleagues, and to do everything right at once.

Be prepared to rewrite the code multiple times.

High-quality architectural solutions are good for their stable work and the fact that they save time and resources on supporting and operating the product. However, in the case of a complex product, it is rarely possible to do everything right at once - surely some elements of the system will not work optimally, and this will have to be done.

Understanding exactly where improvements are needed can be very difficult. An example of such a situation is the development of the functionality of the system events of our Hydra billing. Such events imply some change of important parameters, which requires certain actions from the system - for example, when the balance of funds in the account drops to zero, the subscriber should disable access to the service. Obviously, an event in this case should carry some information about the subscriber, for example, its identifier, MAC address, etc. It all seemed correct and logical at the design stage, but then problems started. For example, under certain circumstances, the system worked out differently than expected in the subject area: someone changed the service code, and it was used in the access command, should the events be re-created for all subscribers?

It turned out that the implementation of the events was a time bomb. The code of this module became very difficult with time, and the problem of lack of access arose constantly, and it became not immediately known about it - events did not re-create until something happened directly to this subscriber, and when this happened, it was necessary to call the medium to determine the reasons. The developers were afraid to touch this code, so that fixing one did not break the other.

So the idea, which initially seemed good, demanded a complete change of concept - not to say that it was easy and pleasant, but we had no way out. You should always be ready for this. Our experience suggests that rewriting gives a chance to do everything right this time, but for this you need to carry out preparatory work and deeply analyze the shortcomings of the previous approach.

Conclusion

When working with complex systems, including billing, it is impossible to do everything correctly once and for all. However, following a few simple rules reduces the number of possible problems and makes it easier to work with the product in the future.

Other articles on IT infrastructure from the Latera team:

• Weekdays billing: How we prepared for the denomination in Belarus
• How to make migration to a new billing easy and understandable: automate data transfer
• We automate the accounting of addresses and bindings in IPoE-networks
• Developing an application to increase the efficiency of field staff: Experience Planado.ru
• What else affects the infrastructure: How to ensure the quality of equipment installation