Universal platforms are evil
Translation of the article “Core Frameworks Don't Work (most of the time)” by Rudy Lacovara, in which he criticizes the practice when companies create their own universal software development platforms, based on which they implement several completely unrelated projects. The picture shows the Borg of Star Trek, a cyborg race that assimilates all organisms into a single super-organism.
I advise serious software companies that support large .net-based information systems with millions of transactions per day. As a rule, my contract with them lasts from 1 to 2 years. During this time I manage to dig deep enough, and at the same time I managed to work with many different companies. This allows me to make interesting observations and conclusions about their software development processes. I am a kind of Nikolai Drozdov, who observes the natural behavior of advanced software companies in their natural conditions.
')
Often, I see one interesting practice called the “universal framework” . Some companies call it “our platform”, “our framework”, others call it simply “core”. But no matter how you call it, the practice of such a universal platform, as a rule (but not always), is an evil that negatively affects the final productivity of your company.
I want to clarify that this article deals with a universal software development platform that a company uses to implement its various projects. This is not the same as the application core.
The core of an application is usually a business logic layer that is used by various modules on the application layer in a single project. For example, the core of a SquareHire application is used in a website, web application, web admin, handler, and API. All of these different modules work with some common data and back end functionality. Together, they constitute a single SquareHire project, so highlighting the common core of an application for them is good practice.
The universal platform is something completely different. Imagine that a company has several projects that are not connected by common data and back end functionality. Perhaps they have nothing in common. Nevertheless, the company wants to make their software architecture as standardized as possible, so the decision is made to implement each project based on a common “universal platform”. Often, such platforms are named after the company, for example, AcmeInc.core. This leads to the fact that completely unrelated projects share a common architecture and code base. It is about this practice that I want to tell.
Imagine that a company has successfully implemented a project. The project continues, the company grows and more developers are hired. There are new features, but they are made by developers who are completely unfamiliar with the original design. They simply write code that solves a specific problem in the way they are used to. And this code does not follow the patterns that were developed in the original design of the project, it just solves the problem. And it may even be that the new approach is better than the old design.
Time passes. The company is becoming even more successful, the project has more users, and now it is supported by a completely new team of developers who do not know anything about those who originally created the project. Each new wave of developers implements new features in accordance with their ideas about how to make them better. New features give rise to design conflict and cover the original design as tumors.
So some more time passes. The company has become so successful that it is already developing several projects, or perhaps they have been bought and absorbed by another software company with many of its projects. No matter how it turned out, but now the company has many projects and each project has its own team. All projects have a different architecture and each of them becomes more difficult to maintain, as each new project team does everything in it in its own way.
At this moment, someone comes up with a brilliant idea: “I know how we can do projects an order of magnitude more efficiently, and all our programs will work much better! It is enough for us to develop one ideal standard architecture, and for everyone in the company to move to its basis. We will create a set of basic libraries, and we will make each new project on them. ”
At first glance, the idea of a universal platform makes sense. You can find some strong arguments for developing such a standard common platform. Here are some of them:
1. Development from scratch will be faster and easier.
New projects will be much easier to bring to a working condition. For them, it will not be necessary to write a bunch of standard code, they will receive everything they need from the platform.
2. Forming teams easier
With a common platform, it will be easier to move developers between teams. After all, they will already be familiar with the architecture.
3. We will be guided by the strongest and most experienced professionals.
Since the platform will be designed by an experienced architect (or architects), it will embody the best possible architecture, and will also oblige to implement the best design techniques for all developers, even the weakest, who otherwise could have gone the wrong way.
Perhaps in the last paragraph I was a little overdone with sarcasm, but the creation of such a platform really seems like a great idea on paper.
In theory, everything sounds cool, but in practice everything is not so rosy. I will share real observations that I made in real companies that were at different stages of their universal platform implementation. I want to say that the architects and developers in these companies were among the coolest professionals with whom I have ever worked. Therefore, the problem clearly was not a lack of experience or professionalism.
1. Development from scratch will be faster and easier.
The platform can really speed up the implementation of the initial phase of a new project, but this is not for long. Pretty soon, developers discover that it, along with the advantages, imposes its limitations. Soon, the developers of the new project begin to schedule meetings with the architect and the platform team in order to understand how to modify it to adapt it to the needs of their project. Do you understand what is happening? The platform is not only not suitable for a new project, but a new project is beginning to influence the platform. And this happens with every project that uses it. As a result, we get a strong relationship between all projects. Now imagine that one day you are upgrading your platform version to the last one in your project and discover that the whole project is broken, because the other team decided that there is a better way to manage transactions, or they changed the DI container, or something else. Submitted?
2. Forming teams easier
It really works to a certain extent. Different projects of the company have a similar structure, so it is easier for developers to switch between them. Unfortunately, there is a reverse side of the coin.
The worst consequence is that development is becoming equally slow and difficult everywhere. After all, the platform generates inter-project dependence, when any change by one project team affects all other teams. It also means that if you need to make a change to it, it will not happen quickly. You will have to wait for it to be coordinated with architects and other team leads.
I also noticed that having a platform makes it difficult for a company to hire new developers. As a rule, with the development of the platform its complexity increases sharply. Managers often complained to me how difficult it is to find developers, and even after finding it takes 5 or 6 months to get a real return, and all because the architecture of the project is very complicated. Should the platform be so complicated? No, but for some reason this is always the case ... which leads us to argument number 3.
3. We will be guided by the strongest and most experienced professionals.
The platform is always created by the best developers in the company. And this is very good, right? Unfortunately no. Here are two big problems.
The first problem is the varying motivation. When a team of developers work together to release a software product, all the motives for their actions lead to the same goal - to release this product. And if product release is postponed - it becomes a common problem for everyone. But when you take away your best developers from the teams and tell them that now their goal is to create a universal platform on which all your projects will be implemented, their motivation becomes completely different. The release of a particular product is no longer their problem. Now they are concerned about such things as, for example, creating a cool architecture, developing new techniques for modeling business logic, exploring new technologies, teaching other developers how to use the platform, etc. The bottom line is that there is a difference in motivation.
The second problem is an interesting phenomenon, which I called “Tough Developer Syndrome” ( “Smart Guy Disease” ). I met him many times in different companies. It lies in the fact that the most fatal mistakes that cause the greatest damage to the company, for some reason, are always made the best of its developers, and not mediocre. If you're interested, here I wrote a whole article about it.
Creating your own universal platform can seem like a “silver bullet” for management and architects. But I warned you. After all, monsters appear. I have never seen any such platform that was able to solve more problems than those that have already been solved. But I saw how, in two cases, the platform led its company to a very difficult situation. So think twice before going in that direction.
I can offer this alternative: create a universal source code base. But instead of inheriting and using it in each new project (which will lead to inter-project dependency), just fork it every time. In this case, you will have a reliable starting point, but at the same time you are free to make changes, without worrying about how they will affect other projects of the company.
I advise serious software companies that support large .net-based information systems with millions of transactions per day. As a rule, my contract with them lasts from 1 to 2 years. During this time I manage to dig deep enough, and at the same time I managed to work with many different companies. This allows me to make interesting observations and conclusions about their software development processes. I am a kind of Nikolai Drozdov, who observes the natural behavior of advanced software companies in their natural conditions.
')
Often, I see one interesting practice called the “universal framework” . Some companies call it “our platform”, “our framework”, others call it simply “core”. But no matter how you call it, the practice of such a universal platform, as a rule (but not always), is an evil that negatively affects the final productivity of your company.
Essence of the phenomenon
I want to clarify that this article deals with a universal software development platform that a company uses to implement its various projects. This is not the same as the application core.
The core of an application is usually a business logic layer that is used by various modules on the application layer in a single project. For example, the core of a SquareHire application is used in a website, web application, web admin, handler, and API. All of these different modules work with some common data and back end functionality. Together, they constitute a single SquareHire project, so highlighting the common core of an application for them is good practice.
The universal platform is something completely different. Imagine that a company has several projects that are not connected by common data and back end functionality. Perhaps they have nothing in common. Nevertheless, the company wants to make their software architecture as standardized as possible, so the decision is made to implement each project based on a common “universal platform”. Often, such platforms are named after the company, for example, AcmeInc.core. This leads to the fact that completely unrelated projects share a common architecture and code base. It is about this practice that I want to tell.
How does this happen?
Imagine that a company has successfully implemented a project. The project continues, the company grows and more developers are hired. There are new features, but they are made by developers who are completely unfamiliar with the original design. They simply write code that solves a specific problem in the way they are used to. And this code does not follow the patterns that were developed in the original design of the project, it just solves the problem. And it may even be that the new approach is better than the old design.
Time passes. The company is becoming even more successful, the project has more users, and now it is supported by a completely new team of developers who do not know anything about those who originally created the project. Each new wave of developers implements new features in accordance with their ideas about how to make them better. New features give rise to design conflict and cover the original design as tumors.
So some more time passes. The company has become so successful that it is already developing several projects, or perhaps they have been bought and absorbed by another software company with many of its projects. No matter how it turned out, but now the company has many projects and each project has its own team. All projects have a different architecture and each of them becomes more difficult to maintain, as each new project team does everything in it in its own way.
At this moment, someone comes up with a brilliant idea: “I know how we can do projects an order of magnitude more efficiently, and all our programs will work much better! It is enough for us to develop one ideal standard architecture, and for everyone in the company to move to its basis. We will create a set of basic libraries, and we will make each new project on them. ”
The idea of a universal platform
At first glance, the idea of a universal platform makes sense. You can find some strong arguments for developing such a standard common platform. Here are some of them:
1. Development from scratch will be faster and easier.
New projects will be much easier to bring to a working condition. For them, it will not be necessary to write a bunch of standard code, they will receive everything they need from the platform.
2. Forming teams easier
With a common platform, it will be easier to move developers between teams. After all, they will already be familiar with the architecture.
3. We will be guided by the strongest and most experienced professionals.
Since the platform will be designed by an experienced architect (or architects), it will embody the best possible architecture, and will also oblige to implement the best design techniques for all developers, even the weakest, who otherwise could have gone the wrong way.
Perhaps in the last paragraph I was a little overdone with sarcasm, but the creation of such a platform really seems like a great idea on paper.
Universal platform in practice
In theory, everything sounds cool, but in practice everything is not so rosy. I will share real observations that I made in real companies that were at different stages of their universal platform implementation. I want to say that the architects and developers in these companies were among the coolest professionals with whom I have ever worked. Therefore, the problem clearly was not a lack of experience or professionalism.
1. Development from scratch will be faster and easier.
The platform can really speed up the implementation of the initial phase of a new project, but this is not for long. Pretty soon, developers discover that it, along with the advantages, imposes its limitations. Soon, the developers of the new project begin to schedule meetings with the architect and the platform team in order to understand how to modify it to adapt it to the needs of their project. Do you understand what is happening? The platform is not only not suitable for a new project, but a new project is beginning to influence the platform. And this happens with every project that uses it. As a result, we get a strong relationship between all projects. Now imagine that one day you are upgrading your platform version to the last one in your project and discover that the whole project is broken, because the other team decided that there is a better way to manage transactions, or they changed the DI container, or something else. Submitted?
2. Forming teams easier
It really works to a certain extent. Different projects of the company have a similar structure, so it is easier for developers to switch between them. Unfortunately, there is a reverse side of the coin.
The worst consequence is that development is becoming equally slow and difficult everywhere. After all, the platform generates inter-project dependence, when any change by one project team affects all other teams. It also means that if you need to make a change to it, it will not happen quickly. You will have to wait for it to be coordinated with architects and other team leads.
I also noticed that having a platform makes it difficult for a company to hire new developers. As a rule, with the development of the platform its complexity increases sharply. Managers often complained to me how difficult it is to find developers, and even after finding it takes 5 or 6 months to get a real return, and all because the architecture of the project is very complicated. Should the platform be so complicated? No, but for some reason this is always the case ... which leads us to argument number 3.
3. We will be guided by the strongest and most experienced professionals.
The platform is always created by the best developers in the company. And this is very good, right? Unfortunately no. Here are two big problems.
The first problem is the varying motivation. When a team of developers work together to release a software product, all the motives for their actions lead to the same goal - to release this product. And if product release is postponed - it becomes a common problem for everyone. But when you take away your best developers from the teams and tell them that now their goal is to create a universal platform on which all your projects will be implemented, their motivation becomes completely different. The release of a particular product is no longer their problem. Now they are concerned about such things as, for example, creating a cool architecture, developing new techniques for modeling business logic, exploring new technologies, teaching other developers how to use the platform, etc. The bottom line is that there is a difference in motivation.
The second problem is an interesting phenomenon, which I called “Tough Developer Syndrome” ( “Smart Guy Disease” ). I met him many times in different companies. It lies in the fact that the most fatal mistakes that cause the greatest damage to the company, for some reason, are always made the best of its developers, and not mediocre. If you're interested, here I wrote a whole article about it.
Conclusion
Creating your own universal platform can seem like a “silver bullet” for management and architects. But I warned you. After all, monsters appear. I have never seen any such platform that was able to solve more problems than those that have already been solved. But I saw how, in two cases, the platform led its company to a very difficult situation. So think twice before going in that direction.
I can offer this alternative: create a universal source code base. But instead of inheriting and using it in each new project (which will lead to inter-project dependency), just fork it every time. In this case, you will have a reliable starting point, but at the same time you are free to make changes, without worrying about how they will affect other projects of the company.
Source: https://habr.com/ru/post/261445/
All Articles