“The first step towards improvement is standardization. Where there are no norms, there can be no improvement. ”

In this article, a thought experiment awaits you, during which I will show what standardization of software development can give the company and the problems that it can lead to. The article does not claim to be the full coverage of this big topic, but, I hope, it will have the minimum that will allow you to take a fresh look at the development in your company.

The conclusions and practical recommendations that I write about are derived from my standardization experience in one of the largest IT developers in Russia. Therefore, all names are fictitious, any coincidences are random.

In the text, you will find some terms from the front-end, in which I have been working for the last several years, let this not bother you, the principles themselves are applicable in other areas of development.

Suppose for a couple of years two companies have been developing web applications for their own business and third-party customers. Each company has four developers, two in two teams.

In the first company, I will call it Diversity, developers are constantly trying technological innovations and like to argue with each other about the advantages of different technologies. One team writes in TypeScript and uses React, the second team prefers JavaScript without typing and uses Vue (substitute your favorite technologies and frameworks here).

In the second company, let it be Standard & Co, they decided to standardize the development and they all write on the same stack with detailed development regulations, let it be React and Flow (typed JavaScript).

Let’s see how these companies will cope with the traditional tasks of a web application developer, and how standardization will help (or interfere) with their solution in Standard & Co.

General problems and solutions

Stack standardization

Imagine that both companies decided to implement calendars in their applications with a convenient choice of date ranges. What will happen in this case?

Most of the developer’s tasks are of the same type and already have solutions. Often, work comes down to finding a ready-made solution on the Internet and adapting it to the needs of a particular project.

In the example with calendars, developers will first google ready-made solutions for their frameworks and choose those that are easier to adapt to their needs. In Diversity, developers will have to do this work twice, for the first team, and for the second, different frameworks do not allow common solutions. In Standard & Co, this work can be entrusted to one team, the second team will be able to quickly take advantage of the achievements of the first.

If we are talking about development from scratch, Standard & Co will be able to divide the work between the teams, in Diversity both teams will have to complete the entire volume on their own.

The project managers of each of the teams of both companies write optimistic reports, the development goes on as usual, the developers perform their tasks in a normal mode, but if you look at the efficiency of the company as a whole, Standard & Co solved the problem with fewer resources.

Moral: a single stack is the first step towards standardizing software development.

Application template

Standard & Co’s business is developing, the company is constantly creating new applications, so the developers decided to create a common template for them so that teams can start quickly and not waste time developing typical architectural solutions. In addition to the most basic things, we decided to include a module of requests to the server in the template, standardized error handling, displaying notifications, loaders, modal windows, etc. Both teams create standard parts of applications equally, quickly and automatically.

In Diversity, teams try new modules and solutions each time independently, at lunch they enthusiastically tell each other about their findings.

Standard & Co is again ahead in terms of overall performance, they have eliminated the time spent on repetitive tasks.

Moral: standard architecture saves time.

Library of standard solutions

A common library of ready-made solutions (or even not one) sooner or later appears in every company that creates software. In the frontend, this is a library of interface components. Developers usually look for a suitable open-source (or paid) solution or create their own library.

Standard & Co checked the pros and cons and decided to create one common library of ready-made components (calendars, autocomplete search strings, etc.) themselves with an eye on their own design system.

Diversity continues to experiment with technology and can even boast of having multiple libraries in one application. For each individual task, an ideal module is selected. This is an interesting task, but sometimes such modules require a lot of time for integration.

Both companies came to one conclusion: the use of libraries of ready-made solutions frees up the time for developers to implement business logic, i.e. creating value for the customer. But Standard & Co also discovered some additional effects from using the shared library. Read on!

Testing

Another plus that Standard & Co has discovered while using common solutions is the reduction in the number of errors in applications. The fact is that the general solutions that are used in both teams are tested in different scenarios, and with each new application these scenarios become more and more. The company’s confidence in the reliability of common solutions and libraries is growing over time. One of the axioms of testing is that there is no software without errors, therefore, the increased resource for testing general solutions constantly improves the quality of the final product.

Diversity is at greater risk by constantly integrating new solutions. It has to spend considerable effort to maintain the required quality of its applications.

Project rotation and people

The situation on the market has changed, both companies had to suspend development in one of the teams for a while, while the other team, on the contrary, added work and shortened the time it took to launch the product on the market.

Standard & Co quickly reinforced the second development team from the first, avoiding downtime and finding new developers. Switching to another project did not take much time, the developers again plunged into a familiar environment, they only had to deal with business logic.

It is just as easy Standard & Co solves other issues with the redistribution of people on projects, whether it transitions from team to team due to personal preferences or team merging.

In Diversity, the management faced a difficult choice: to retrain the developers of the first team on the technologies of the second, with which, by the way, not everyone will agree, or to open vacancies and recruit new developers. In any case, additional time is required to strengthen the second team and may be easy to work the first.

Planning

Diversity has already accumulated sufficient planning experience and understands how much time needs to be laid in order to take into account development risks.

In Standard & Co, planning has its own characteristics. Due to a large number of standard solutions, project managers accurately plan the development time and do not put additional risks in standard projects. To do this, you need to figure out in advance which parts of the application will require non-standard solutions. If development does not go according to plan, the consequences can be serious.

Company growth

Marketers have announced next year a year of business expansion in both companies. So far, the exact scope of work has not been determined, but you need to start preparing for growth now. It is necessary to expand the development and hire new people.

Standard & Co solves the issue by hiring novice developers who can learn and gain experience in any of the two teams, and then stay in them or work on common standards as independent teams. Thanks to the standardization, any permutations are possible.

Diversity decides to recruit a new team, which will independently determine what technologies it will work with, you need to be aware of technological trends. They will probably do better than the first two, but it’s better to prepare for the unexpected.

Control over development and code review

After the emergence of a new team, Standard & Co developers take turns reviewing the code for beginners, teaching them how to work according to company standards and learning from them new knowledge. Almost any company employee with sufficient development experience can control the development of a new project, everything is standard there. Control and review require resources, here Standard & Co again has space for optimization.

At Diversity, management has to rely on development leads. Only well-established professionals fall into these positions in the company. The company relies on the honesty and professionalism of these guys, appreciates their contribution, constantly takes care of their professional development and high motivation.

Effective communication

Diversity programmers love to argue about which technology is cooler. From the outside, these disputes may look like battles of the titans. Experienced developers put each other on the shoulder blades with another elegant attack in the enemy’s weak spot. However, they made a noise and parted. Typically, such battles are attractive, but not effective.

The developers of Standard & Co after such conversations go to refine the code common to them. By helping themselves, developers help others, and vice versa. Even after the recent recruitment of new developers, Standard & Co conducts training events. Once a week, one of the developers parses a technical question from daily practice, now you can usefully talk about general topics during business hours.

Modernization and rapid technological improvements

Standard & Co discovered another advantage of standardization after the release of a new version of the TypeScript language. It seemed to developers more convenient for development than Flow, which they had long been using. Standard & Co developers rewrote the application template and library of interface components in TypeScript, making development easier and more concise code.

No matter how many teams the company has, after updating common templates and libraries, the new functionality immediately becomes available to everyone and undergoes versatile testing and testing. The initiative for modernization can come from any of the teams, the collective mind is already monitoring the relevance of the stack in Standard & Co.

In Diversity, each team has to independently monitor the relevance of its stack and timely update the technological base, which requires additional time and labor.

Negative effects of standardization

Loss of qualifications

The developers at Diversity are real professionals with a broad outlook and wide experience in various technologies, and Standard & Co has many beginner developers and similar simple tasks, often programmers get bored and want new challenges.

If a developer carries out standard routine operations all the time, he may stop developing and become interested in technologies. In such circumstances, someone may even stop seeing their value outside the same company and constantly lose their motivation, and even end up with instead of creative work just going to work for a salary. Yes, and this salary itself will not be high and will not grow rapidly, because the system is configured to standardize and simplify the work of each individual employee and increase the productivity of the system as a whole.

Standardization can adversely affect the level of programmers.

Standard & Co understands this problem and tries to stimulate the creative energy of its developers and direct it towards the search for more effective solutions in their own development process, deepening fundamental knowledge, constant updating of the stack and self-education. It is very important that Standard & Co invests money and other resources both for technological development and for building a career plan for its employees.

Snapping to stack

The Diversity business model allows you to take into development a project, part of which is already ready or for which the customer has defined a technology stack. To do this, she needs to form a new team and establish processes in it, which is not difficult for Diversity, given her previous experience.

The management of Standard & Co will try to agree on the transfer of the project to technologies already familiar to it. If negotiations do not lead to the desired result, most likely the company will abandon the project, new technologies for the company are a source of great risks.

Deviations from standards – a source of progress and mistakes

New Standard & Co developers often have the temptation to use something else, perhaps more suitable for a specific task, instead of the standard solution. In this case, the company management offers to carefully weigh the pros and cons.

If the new solution turns out to be noticeably better than the standard, then it must be included in the standard and used in all teams.

If the new solution, along with the advantages, also has disadvantages compared to the standard, or its advantages are small, such a solution should not be used. It will lead to additional time spent on development, review, testing, training and more. New developers will have to spend more time studying the technology of the project.

Custom solutions may contain errors. The time required to fix a non-standard code is usually longer than the time to complete a standard, already familiar code.

Standard & Co has developed special programs that motivate developers, on the one hand, to adhere to standards, on the other hand, to constantly improve them.

Standardization does not happen on its own

It might seem that Standard & Co is saving time and money all the time thanks to standard development solutions. This is true, but the picture will be incomplete if we do not take into account the costs of the standardization process itself.

Standardization needs to be directed, someone must develop the standards themselves, write the regulations, create the infrastructure, constantly motivate colleagues to use standard solutions, control their correct understanding and application. This requires time and effort that Diversity can spend on a new project, training, or improving working conditions.

Someone must constantly review and improve the standards themselves, otherwise the company will face technological stagnation. In the front-end, this is especially dangerous, just a couple of years, and you are the happy owner of a heavy legacy, which takes resources from the company.

The two characters in the beginning are “kaizen”, the Japanese philosophy of constantly improving the processes of production, management, business, life. Standardization is one of the principles of this philosophy. In the middle of the last century, Toyota applied kaizen principles, and as a result received the now famous Kanban system.

Standardization accelerated the development of industry, and gradually changes the development of software. But here it’s not so simple, it’s more difficult to change human thinking than a milling machine.