The business applications are developed. They need to be developed. It is obvious. But how fast this can and should be done?
Of course, in general, this is an age-old question. Almost philosophical. There is no a single correct answer on it. More precisely, it is necessary to answer on it all the time. Too bad you can not make a decision once and then always follow it.

In the title of this article two sides of one question are combined: the permissible development speed and the required development speed.

The first side of the coin is a permissible speed of business application development. If you do not consider the abilities of supplier, then it is limited by the ability of the users and specialists to go to the new product versions without losses. Under the losses we understand here also the psychological difficulties occurring because of unfamiliarity, imposed need of learning something new, reflections in a current work, etc.

Of course, these losses can be partially compensated by different methodical materials, the smoothness of transition on a new version (as it is possible), etc. However, these losses are compensated best of all by the evident, obvious for the user or specialist advantages. But, unfortunately, it does not always work.

Often, for example, the new is perceived as more convenient and effective not immediately, but only after some time.

Sometimes the new is perceived by only new users. Because it is more understandable. And an understandability is just needed primarily for the new users. After all, the users who work for a long time have learned already everything.

But the most «difficult» thing is when the new does not pose any immediate tangible benefits for the users. When the new is needed to solve some strategic tasks that are extremely important for vendor, for specialists and for the users themselves in the final analysis too. But it is hard for the users to feel «here and now». This will occur gradually. And for this reason. It will be hard for users to see the direct relations of the changes and transition difficulties that occur now with the benefit received by them later.

The second side of the coin is the required speed of business application development. It is caused by the dozens of various trends and possibilities. These are the trend of social development, the technological trends and, at last, a simple desire «to do better». Often, the individual trends and directions of development are in conflict with each other, but this is normal.

The important trend is that the changes in life itself become faster. At least in the part that affects IT.

Another significant aspect, as it seems, is that the approaches and trends in IT become less dogmatic. IT-industry began less «to march in formation». Earlier usually it was clear that «the modern program should have that interface», «the modern architecture should look like so ». But now in the most of aspect there are several parallel approaches that compete with each other and complement each other at the same time.

Under these conditions one has to focus on not the main mass of users, but on their vanguard that actively «finds out» the new realities: devices, scenarios, approaches to the system work, etc. Nut the new opportunity must be not only implemented in an amicable, but also to bring more or less to a practical usage. And it turns out that you need to have a time to do all of this before the new possibility becomes essential. Because when the need in it will be urgent not for the vanguard of the users, but also for the basic masses, it will be too late to create and produce a new solution.

Of course, all of the above is the common words. But in practice we need to make the particular decisions. When and how to implement the significant changes in platform? How to make a new edition of application solution and with what level of innovations? What transition method is it possible to use? How much can you modify the interface?

Of course, these problems are common for all the business software suppliers which have at least thousands of the users. Especially they are urgent in our case, when we are talking about the millions of users.

In this dilemma – to develop or to wait – there is one more difficult aspect – the question of stability and quality. Of course, we all know the answer of dad-programmer to the question of boy from the famous funny story: «if works – do not touch».

If nothing is changes or changed not much, then it is much easier to ensure the stability and quality. And if you develop the system and all the more develop actively, it is harder to ensure the stability and quality.

But there is another, just the reverse aspect. Often, it is impossible to reach the significant improvement of just the quality without significant changes.

For example, in version 8 in process of development we carried out the full refactoring of large and responsible mechanisms. In fact, we wrote them from scratch. We understood that without such a drastic measure by only correcting the errors and making improvements we will not able to ensure the necessary quality and development of the system.

Of course, the situation is more complex when to raise the quality it is required to reconstruct not only the internal architecture, but also the model provided for the specialists and end users. This also occurs during the development of platform and development of application solutions.

Of course, besides improving the quality using remaking the architecture during the fast system development it is required significantly more efforts for the regular processes too: debugging, testing, correcting the errors. We understand that we need to significantly improve these processes. At least because the requirements to the quality are objectively increased.

When we discuss with the users and partners these problems, of course, we receive directly contradictory assessments and recommendations. In general, it cannot be different here. From «why do you develop so fast» to «when will you implement at last…». And we understand that these are not the different opinions of different people. Just at any given moment a person has more «sore» (disturbing, calling the problems) either one or another side of the problem.

There is also such an observation in which, unfortunately, it is hard to believe. Some aspect in technology and application solution can be not needed now by the particular users and specialists, but will be valuable for them with its existence of possibility.

For example, the ability of real remote work or the work through browser was not seen by many users and specialists as something necessary. As long as this requirement has touched exactly them badly. But many specialists understand that the presence in their arsenal of such possibility protects them from critical situation when the success of an entire project will depend on the presence of this ability. It is well when «the users needed and we already have it ».

Another important moment is the smoothness of migration from previous versions. Those who are working closely with «1С:Enterprise» platform may have noticed that recently we invest more in migration smoothness. We understand that the total value (cost, importance) of applications developed with «1С:Enterprise 8» is huge.

At first we had a simple conversion. Later we introduced a concept of compatibility mode in which the new platform emulates the work of old one in many aspects. Sometimes the emulation is executed «paranoidly» replaying even the erratic behavior of old version that did not change the application behavior.

Later we implemented even the modification of data structures when changing the compatibility mode. That is, the new version can «turn the mince back»: restore the old data structure when the emergency rollback to the previous version is needed.

And in version 8.3.3, besides the previous compatibility mode, we made two more separate compatibility modes. The mode of interface compatibility (the old interface of the new on «Taxi» can be used) and the mode of modality use (it is possible to work as before or disable the user of modality – the recommended mode). Thus, now the developer can transfer his applications to the new version gradually and can rollback on the previous version if necessary.

Of course, the compatibility support at this level is given very difficult. This is the significant effort in development and the significant load of testing. But we believe that it is paid by itself.

One of the development approaches that we use we compare during discussion with rearrangement of the cabinet. Have you ever tried at home to move alone the cabinet from one corner of the flat to another? If you tried, of course, you know that there are several methods («patterns»).

For example, you can put under a piece of cardboard and drag. You can buy the special wheels that are placed under the edges of the cabinet. Or you can move the cabinet piecemeal. Raise one of the edges, rotate it by a small angle around the leg of other side and so on.

The same approach can be used also in development of business applications. In this case we talk both about the platform and the applications. To change on particular stage some aspect, but do not touch the other aspects. This allows you not to «bring down» on the users and specialists the changes from all the fronts at once. And thus allows to stay on a thin edge of acceptability of the changes.

And also the need to maintain the desired development speed leads to a fairly complex process of planning and development. For example, our platform development is now conducting simultaneously with up to five planning horizons.

In version which we release in 2–4 weeks, and if necessary in 1–2 days, we apply a carefully selected set of fixes of the critical bugs. In version released with interval of 3–4 months we include a small, the most critical improvements of functionality and a wide range of the bug fixes. In the third horizon we apply a significant number of functional changes. And there are two more horizons. With the increasing of horizon level increases the scale of changes.

If to try in conclusion to answer the question «So, how is better?», we still believe that the development must be fast, and it should be accompanied by all sorts of measures that provide the acceptability of this rapid process for the users.

There are many things that will be required tomorrow and it was necessary to prepare them yesterday. We see that in addition to all that we are actively developing, there are many aspects that should be developer more quickly. And in any case we have to choose which system aspects to develop on the current stage with the maximal priority. But the choice of priorities is already another topic.