Approach to Team Discussion: Part 2
The article turned out to be long, so I split it into 2 parts. The focus of the first part is on the importance of abstracting from specifics at the beginning of problem discussion. How to turn the discussion into a constructive stream and get the maximum for decision-making. This part describes what to do when requirements are agreed upon internally and the discussion returns to decision-making, and what to do if there are several equivalent solutions.
Moving on to solutions
So, we came to the point where at the beginning we discuss the requirements that need to be taken into account in the decision before going into any technological specifics. The team agreed on the goals and the points that need to be achieved. Now we finally need to move on to the solution and discuss one or another idea.
Suppose we have several solutions and all of them already meet the requirements. Solutions that do not meet the requirements are not considered by default. More precisely, if we imagine collective work - then we gently remind that some requirement is not considered in the solution and it needs to be either expanded or not considered.
More about the situation
For those who have never been in such a situation - imagine that you have some solution based on requirements. But there are proposed alternatives. These alternatives may look like a conceptually different proposal or just a proposal to adjust the initial solution. For example, you have a proposal to create a system consisting of 3 components, and someone suggests splitting one of the components into 2 parts, thereby designing a system consisting of 4 components. Roughly speaking, they ask: "Why not do X?" While the previous system satisfied the requirements. Or did it not...?
Why alternatives arise
If you think about it a little, we are all humans :) Your captain.
There are always many solutions to the same problem.
What is important to understand is that when you start practicing a non-routine, non-inertial approach, it always turns out not 100% perfect. I would say that the first attempts are good if they work out 50%.
People who offer alternatives think that they have come up with a way to take more into account. That is, they come up with a new requirement that, as it seems, should improve the design and take into account more possible developments. Or less, because someone might think that the current solution is unnecessarily complicated. At each stage of proposing an alternative, the most important thing is to constantly return from the solution level to the requirements level. Again, we understand why the solution is better through the prism of additional quality attributes they add to the system.
How to decide which solution to choose
If the alternatives are equivalent, you can of course flip a coin. Just kidding.
It's better to approach this process more consciously and get some benefit from the situation. If the alternatives make some changes to the requirements, then we make a collective decision whether this requirement is necessary or not. Usually this is quite easy to do if everyone on the team is reasonable. For example, you can do a simple pros and cons analysis. Based on the analysis, you can understand whether the requirement provides benefits considering all compromises.
Example
Let's imagine a situation where we have a task to design communication between several services. There is a proposed option to use HTTPS and request-response that satisfies all initial requirements. But at the same time, someone on the team suggests putting a queue between the services.
We bring the conversation to the level of requirements. What does the proposer want to take into account through the queue? We get the following answer:
- Reliable application. The queue can act as a buffer and in case of failure of one of the components.
- Communication tolerant to load spikes. Again, the queue acts as a buffer and allows you to wait until all messages are processed, or already provide smart scaling based on the size of the queue.
Okay, we got the requirements. Now we discuss whether we need them or not. Are they mandatory?
- We discuss reliability - it looks like something necessary. But there are various levels of reliability such as availability, fault tolerance, and recoverability. We agree that 99.95% availability, fault tolerance in case of failure of several running copies of the application will be sufficient.
- Next, we discuss communication tolerant to load spikes. We say that having such a characteristic would be good if there is a conditionally cheap way, but it is not critical for our current requirements. Much more important is the ability to recover after load spikes.
Now we have updated requirements and 2 solutions that fit all the requirements. Let's now make a pros & cons analysis.
Choosing HTTPS request-response
| Pros | Cons |
|---|---|
| Communication that is naturally supported in browsers | No built-in retry mechanism |
| Clear error handling | Message processing is not guaranteed |
| Simple way of communication for developers | |
| Availability of ready-made tools for testing and debugging |
Choosing Queue
| Pros | Cons |
|---|---|
| Guaranteed message processing | Complex error handling |
| Provides a message buffer in case of abnormal situations | Requires a separate UX and technologies for delivering responses for browsers |
| Requires additional layers of transport-related logic such as idempotent handlers and routing | |
| Requires additional tools for testing and debugging |
We look at the pros and cons analysis and decide that for us, speed of development and simplicity for developers is more important than the advantages that a queue provides. Therefore, we choose the HTTPS request-response.
It is important to note that during the pros and cons analysis, we also identified another important factor - simplicity for development plays an important role in the current conditions.
Expanding the requirements
After all the discussions, it would be good to document the solutions and requirements that we have derived as a result.
All of this can be immediately included in the documentation as we discuss. It would also be good to document what was rejected and why, as it will help to expedite further discussions. The more requirements that are described or rejected, the easier it will be to build a solution that fits everything.
Checking the Solution
Usually, real life is more complex than a single example taken for an article. There may be much more discussions and documented requirements. From practice, sometimes it took 4-6 hours to discuss complex solutions. After all the changes, it is a good idea to recheck whether the solution obtained at the end still satisfies all the requirements, constraints, etc. To do this, you can take formal methods of traceability of requirements, or at least once go through the requirements visually answering the question "How is it embodied in the solution?". If the answer is there, then everything is good, if the answer is difficult or absent, then it is worth adjusting the solution until all the requirements are covered.
Summary
In two parts, the process of how a team can collectively discuss, find consensus and come up with more quality and pragmatic solutions has been considered. I hope that this will help someone avoid conflicts, unthoughtful solutions, and generally build a more conscious approach to architecture. At least for me, this helped improve the processes a little in my time. And with this article, I tried to structure what has been done.