Project kitchen. Reducing the architectural risks of the project
For my experience in software development, I worked on many projects, and often had to join an existing project or see a new team on my projects pick up a project with a story. Often, a new developer coming to the project and starting to complete the task first of all begins to spit on the existing design. It seems to him that everything was done incorrectly, not obvious and too complicated. And as a result, when the task is completed, holes in the already developed design begin to appear and the existing architecture begins to crush. In the end, the project or its subsystem is required to be rewritten almost completely. The older the project, the more such cases.
Also, there is another extreme, for the implementation of a new functional or alteration of an existing one and the developers say: “I know how to do better!” And then, instead of giving the idea of ​​“lying down” and appreciating all the pros and cons, it immediately begins to do it. Somewhere in a month of development, a situation may arise that he did not anticipate something, and you have to abandon the development and throw out the code or urgently look for solutions to the problem. Almost every developer in this case wants to save face: “How is that? I'm a professional! ”He thinks,“ If I admit my mistake, then everyone will think that I'm not as cool as I say to everyone. ” And in this case, the idea that is not sufficiently developed is included in the project and becomes a problem for the entire team. Which also increases the cost of the project. And since this is not immediately noticeable and almost no one pays attention to the cause-effect relationships, the situation can be repeated again and again.
All the cases described above are quite common on all projects, but especially noticeable in long projects with a duration of one year. But there are a couple of techniques that allow reducing the likelihood of similar cases or eliminating them altogether. This is not a pure theory, but a ready-made recipe, which I apply on my projects.
When developing any software product, there is always a whole set of risks, the onset of any of which leads to an increase in the time it takes to develop a product and, accordingly, to raise the cost of the project. However, among them it is necessary to single out two, in my opinion, the most important ones: this is the bus factor and architectural risk. These two risks greatly affect the predictability of a project. And it is not by chance that I single them out, as connected and important as when the first one occurs, the probability of the second one increases.
')
Under the risk of "bus factor" I understand the loss of important information about the project due to the change of developers. It is important not only who did the project, but what he was thinking at the same time. And usually from the code, even covered with modular tests, it is not always clear why this particular solution was chosen and why it is so difficult if there are many other simple solutions. The cost of this risk I reduce by almost complete documenting of the design decision BEFORE the solution is applied. As well as documenting all tasks to develop or modify the project. This ensures that a one-time change of 90% of the team is safe for the project. Since the basic information about the Idea and its changes is documented, which allows subsequent developers to simply follow the intended scenario without discarding all the wrong options from their point of view, which consequently reduces the likelihood of risks associated with the architecture.
Architectural risk I will call the risk associated with incorrectly chosen architectural solution or a framework or hardware platform. It often happens that the development of any project architecture always has a chance that a new solution will not cope with the tasks assigned to it, or at the most inappropriate moment it will pop up: “Oh, but we didn’t think about it.” After that, as a rule, the inventing of crutches and options for circumventing the problem begins at the implementation stage. As a result, this may lead to an increase in the time and cost of product development.
Take a glass of flour, a glass of sugar ... oh, this is not the recipe.
To prepare a delicious project, and it is not burnt, you will need: Knowledge Base (wikis), Whiteboard, stickers, and several developers ...
Before approaching the search for risks themselves, it is important to solve several issues at the idea level and assess the viability of the idea itself.
I will block the entire movement of the project in any direction with the wording:
- Do you have a brilliant idea of ​​amazing newness?
- Well! Document your proposal on the wiki, we will discuss it.
Of course, the wording “Initiative is punishable”, on the one hand, may come to this case, but on the other hand, this may be the task of pumping the analytical skills of the engineer.
When a new idea is documented, it may lose a little of its colorfulness and brightness, which allows it to better think about it and ask it (the idea) additional questions. Sometimes, after answering this question in writing, it turns out that there is no need to change anything in the system significantly, you need to tweak the existing process a bit, or the system already knows what is contained in the Idea.
This approach has one small drawback, which is important to consider. Beginners (or coders) can give out good ideas, but documentation of an idea in the knowledge base requires a relatively advanced level of analytical skills. And then there are two possible options for the development of the event, on the one hand, the task can be regarded by the executor as the task of developing the skills of the architect, or he can declare that “I am not paid for it” if he does not want to think further. Therefore, it is important here not to overreact and notice in time that there is a desire to analyze the author of the Idea.
If the idea is really worthwhile and requires implementation, then go to step two:
What will the introduction of this solution?
Any change to the project may have obvious consequences and not quite obvious ones, at this step our task is to find all the not obvious consequences of the implementation of the Idea. To find out all the consequences in the Theory of System Restriction (TOC) there is a wonderful tool Future Reality Tree (DBR). therefore, we draw a tree of future reality on the blackboard, we look at the consequences, if there are undesirable phenomena (ULA), then we are looking for options to block such phenomena, that is, in what ways we can reduce the impact of undesirable phenomena on the system. It may happen that undesirable effects appear so much that it makes sense to postpone the Idea until better times. Or, we find more elegant options for changing the system architecture.
Explanation: The tree of future reality is a diagram of causal relationships showing how our change in the system will affect the system after its introduction ( details ).
We found out all the undesirable phenomena and found ways to reduce their impact on our project, however, the question arises:
Will we achieve all the goals with this solution?
To answer this question, you can supplement the existing DBR or draw a new but already built from targets. On the constructed tree should be clearly visible due to what we will achieve our goals. So, as the tree is a cause-and-effect relationship, we can track: “will we achieve our goals?” Or some of the planned goals will remain outside the scope of changes. If some of the goals are not achieved by our decision, or undesirable phenomena appear (NNYa), then it is necessary to think about improving the Ideas so that no NNYA is left open on the tree and all the goals set are achieved.
After this step, as a rule, the architectural solution has a finished look, but this is not a reason to immediately implement it:
How much does solution cost?
Any change to the project costs both money and time. The question is always whether we are ready to invest today or can be postponed until tomorrow. To change the project schedule, additional coordination with third parties (customers, managers, etc.) may be required. At this phase, a new solution needs to be broken down into tasks and evaluated, at least with some tolerances. That will allow, at the time of discussion with stakeholders, to have a detailed plan for implementation and more substantively discuss the time and costs.
We found out almost everything about our new idea, and prepared a subject for negotiations, however:
Are there alternatives and how much do they cost?
There are always alternative solutions, simpler or more complex, but they are. And these solutions also have a cost and a probable “profit”; it may also turn out that an alternative solution will be better than what was originally proposed. But this question can be answered only when the Idea is documented in the knowledge base, and does not spin in the developer’s head in the form “I have an Idea and I now implement it”. It may well be that it is easier to buy a third-party product or even a company than to do some work yourself.
If the answers to these questions show the effectiveness of our Idea, its feasibility and the “low cost” of implementation compared to its analogues, then we ask the most important question:
What can prevent us from implementing / implementing a solution?
When answering this question, we identify all or most of the architectural risks that may prevent us. At one of the recent discussions, the main risks were:
Further development begins with the reduction of architectural risks by developing several prototypes that test each risk for influence. The prototypes themselves are made on the basis of hacker-driven development (I have an idea and I will encode it), therefore, they are quite cheap. While implementing a solution in a project can be quite expensive and time consuming.
At the stage of verification of architectural risks, of course, problems may arise that this or that risk will work, but it makes sense to plan on it immediately and plan work on Plan B where alternative options will be explored. If the risk did not work, then you are lucky, otherwise additional time will be spent on research.
... after 40 minutes, remove from the oven, the cake is ready.
Answers to all questions have been received, all risks have been successfully resolved, your project becomes more predictable and further development will go according to plan, without unexpected deviations.
Colleagues, how do you prepare your projects?
Other recipes
Also, there is another extreme, for the implementation of a new functional or alteration of an existing one and the developers say: “I know how to do better!” And then, instead of giving the idea of ​​“lying down” and appreciating all the pros and cons, it immediately begins to do it. Somewhere in a month of development, a situation may arise that he did not anticipate something, and you have to abandon the development and throw out the code or urgently look for solutions to the problem. Almost every developer in this case wants to save face: “How is that? I'm a professional! ”He thinks,“ If I admit my mistake, then everyone will think that I'm not as cool as I say to everyone. ” And in this case, the idea that is not sufficiently developed is included in the project and becomes a problem for the entire team. Which also increases the cost of the project. And since this is not immediately noticeable and almost no one pays attention to the cause-effect relationships, the situation can be repeated again and again.
All the cases described above are quite common on all projects, but especially noticeable in long projects with a duration of one year. But there are a couple of techniques that allow reducing the likelihood of similar cases or eliminating them altogether. This is not a pure theory, but a ready-made recipe, which I apply on my projects.
Introduction
When developing any software product, there is always a whole set of risks, the onset of any of which leads to an increase in the time it takes to develop a product and, accordingly, to raise the cost of the project. However, among them it is necessary to single out two, in my opinion, the most important ones: this is the bus factor and architectural risk. These two risks greatly affect the predictability of a project. And it is not by chance that I single them out, as connected and important as when the first one occurs, the probability of the second one increases.
')
Under the risk of "bus factor" I understand the loss of important information about the project due to the change of developers. It is important not only who did the project, but what he was thinking at the same time. And usually from the code, even covered with modular tests, it is not always clear why this particular solution was chosen and why it is so difficult if there are many other simple solutions. The cost of this risk I reduce by almost complete documenting of the design decision BEFORE the solution is applied. As well as documenting all tasks to develop or modify the project. This ensures that a one-time change of 90% of the team is safe for the project. Since the basic information about the Idea and its changes is documented, which allows subsequent developers to simply follow the intended scenario without discarding all the wrong options from their point of view, which consequently reduces the likelihood of risks associated with the architecture.
Architectural risk I will call the risk associated with incorrectly chosen architectural solution or a framework or hardware platform. It often happens that the development of any project architecture always has a chance that a new solution will not cope with the tasks assigned to it, or at the most inappropriate moment it will pop up: “Oh, but we didn’t think about it.” After that, as a rule, the inventing of crutches and options for circumventing the problem begins at the implementation stage. As a result, this may lead to an increase in the time and cost of product development.
Cooking recipe
Take a glass of flour, a glass of sugar ... oh, this is not the recipe.
To prepare a delicious project, and it is not burnt, you will need: Knowledge Base (wikis), Whiteboard, stickers, and several developers ...
Before approaching the search for risks themselves, it is important to solve several issues at the idea level and assess the viability of the idea itself.
I will block the entire movement of the project in any direction with the wording:
- Do you have a brilliant idea of ​​amazing newness?
- Well! Document your proposal on the wiki, we will discuss it.
Of course, the wording “Initiative is punishable”, on the one hand, may come to this case, but on the other hand, this may be the task of pumping the analytical skills of the engineer.
When a new idea is documented, it may lose a little of its colorfulness and brightness, which allows it to better think about it and ask it (the idea) additional questions. Sometimes, after answering this question in writing, it turns out that there is no need to change anything in the system significantly, you need to tweak the existing process a bit, or the system already knows what is contained in the Idea.
This approach has one small drawback, which is important to consider. Beginners (or coders) can give out good ideas, but documentation of an idea in the knowledge base requires a relatively advanced level of analytical skills. And then there are two possible options for the development of the event, on the one hand, the task can be regarded by the executor as the task of developing the skills of the architect, or he can declare that “I am not paid for it” if he does not want to think further. Therefore, it is important here not to overreact and notice in time that there is a desire to analyze the author of the Idea.
If the idea is really worthwhile and requires implementation, then go to step two:
What will the introduction of this solution?
Any change to the project may have obvious consequences and not quite obvious ones, at this step our task is to find all the not obvious consequences of the implementation of the Idea. To find out all the consequences in the Theory of System Restriction (TOC) there is a wonderful tool Future Reality Tree (DBR). therefore, we draw a tree of future reality on the blackboard, we look at the consequences, if there are undesirable phenomena (ULA), then we are looking for options to block such phenomena, that is, in what ways we can reduce the impact of undesirable phenomena on the system. It may happen that undesirable effects appear so much that it makes sense to postpone the Idea until better times. Or, we find more elegant options for changing the system architecture.
Explanation: The tree of future reality is a diagram of causal relationships showing how our change in the system will affect the system after its introduction ( details ).
We found out all the undesirable phenomena and found ways to reduce their impact on our project, however, the question arises:
Will we achieve all the goals with this solution?
To answer this question, you can supplement the existing DBR or draw a new but already built from targets. On the constructed tree should be clearly visible due to what we will achieve our goals. So, as the tree is a cause-and-effect relationship, we can track: “will we achieve our goals?” Or some of the planned goals will remain outside the scope of changes. If some of the goals are not achieved by our decision, or undesirable phenomena appear (NNYa), then it is necessary to think about improving the Ideas so that no NNYA is left open on the tree and all the goals set are achieved.
After this step, as a rule, the architectural solution has a finished look, but this is not a reason to immediately implement it:
How much does solution cost?
Any change to the project costs both money and time. The question is always whether we are ready to invest today or can be postponed until tomorrow. To change the project schedule, additional coordination with third parties (customers, managers, etc.) may be required. At this phase, a new solution needs to be broken down into tasks and evaluated, at least with some tolerances. That will allow, at the time of discussion with stakeholders, to have a detailed plan for implementation and more substantively discuss the time and costs.
We found out almost everything about our new idea, and prepared a subject for negotiations, however:
Are there alternatives and how much do they cost?
There are always alternative solutions, simpler or more complex, but they are. And these solutions also have a cost and a probable “profit”; it may also turn out that an alternative solution will be better than what was originally proposed. But this question can be answered only when the Idea is documented in the knowledge base, and does not spin in the developer’s head in the form “I have an Idea and I now implement it”. It may well be that it is easier to buy a third-party product or even a company than to do some work yourself.
If the answers to these questions show the effectiveness of our Idea, its feasibility and the “low cost” of implementation compared to its analogues, then we ask the most important question:
What can prevent us from implementing / implementing a solution?
When answering this question, we identify all or most of the architectural risks that may prevent us. At one of the recent discussions, the main risks were:
- Will we achieve the specified performance?
- Is there any functionality in this framework that we need?
- Is our solution implemented by the means we have in mind?
Further development begins with the reduction of architectural risks by developing several prototypes that test each risk for influence. The prototypes themselves are made on the basis of hacker-driven development (I have an idea and I will encode it), therefore, they are quite cheap. While implementing a solution in a project can be quite expensive and time consuming.
At the stage of verification of architectural risks, of course, problems may arise that this or that risk will work, but it makes sense to plan on it immediately and plan work on Plan B where alternative options will be explored. If the risk did not work, then you are lucky, otherwise additional time will be spent on research.
Total
... after 40 minutes, remove from the oven, the cake is ready.
Answers to all questions have been received, all risks have been successfully resolved, your project becomes more predictable and further development will go according to plan, without unexpected deviations.
Colleagues, how do you prepare your projects?
Other recipes
Source: https://habr.com/ru/post/285884/
All Articles