Price of difficulty
It was always difficult for me to explain even the term “technical debt” to myself. It was never clear who, to whom, for what and how much should. And, if it is a debt, how can it be paid and can it be paid in full? Is it possible to make me owe it?
I recently read an article by Chris Gale from Yammer , which introduces the concept of "complexity cost" (complexity cost), which is much closer and clearer to me. The price of complexity describes exactly the same aspect of developing complex systems as technical debt, which, in my opinion, only adds more clarity.
The idea is extremely simple - the more complex the project, the more effort is spent on its support, the more expensive it is to change it. Although we cannot measure “complexity” in pure form, but this statement is considered true, probably by all engineers.
Chris writes in his article that the time it takes to make new functionality is the smallest part of the cost of this functionality. He gives an example of how he did something for Yammer in 1 hour, and over the next 5 years, he spent 40 hours telling other engineers what it is and how it works. This means that the total for these conversations took at least 80 hours, because another engineer also spent his time on it.
')
The complexity can be divided into two types. The first kind of complexity is the number of functions that the system has. The second kind of complexity is over engineering when implementing a function. And the more features a product has, the more expensive its support and change. This kind of complexity can be reduced only in one way - to remove some function. Chris writes that in Yammer, after adding new functionality, they watch it for a while, and if it is not used and does not bring value, then it is removed. Moreover, they measure how all the functions on the site are used to assess what it is worth investing and what can be discarded.
The second kind of complexity is unnecessary complexity; it is treated only by a mature engineering approach. Instead of doing something “cool” (this disease is not only among Russian young engineers), you need to think about how to do something as simple as possible. Or simplify something that is already used in the project.
For example, in one of my projects there was a task scheduler, which was initially “sharpened under high loads”. It used a multithreaded architecture, and threads were used within each thread. Moreover, a multi-level procedure for rolling back tasks performed by the scheduler was designed. But sober reflection showed that the number of tasks that this scheduler performs is quite small, and a multi-level rollback greatly complicates the writing and support of the project, while all the same, all tasks were rolled back entirely in case of an error. We spent a week trying to simplify the planner, after which its code also decreased significantly and became much easier.
Several times I had to protect projects from the introduction of another “fast” message queue, when the number of messages per day did not exceed several thousand, and everything was fine on the database, which was already used in the project.
In several projects that we advised and on which a relational database was used, we got rid of MongoDB, greatly simplifying their support.
When a manager asks, “How long will it take to do such a thing?”, We must immediately think that this question is almost meaningless, because the time of support and refinement is many times longer than the time to create a new functionality.
It is clear that there are no projects with zero complexity, therefore in any project it is necessary to pay for the complexity. The only question is whether it is possible to do something with the project so that the complexity in it becomes less, and he brings as much money. This is complexity management - the task that a mature engineer solves.
And the questions that I put in the beginning of the article can be turned into just one: “How much do we overpay for complexity?” If this figure could be calculated in money, then this would be a “technical debt”.
I recently read an article by Chris Gale from Yammer , which introduces the concept of "complexity cost" (complexity cost), which is much closer and clearer to me. The price of complexity describes exactly the same aspect of developing complex systems as technical debt, which, in my opinion, only adds more clarity.
The idea is extremely simple - the more complex the project, the more effort is spent on its support, the more expensive it is to change it. Although we cannot measure “complexity” in pure form, but this statement is considered true, probably by all engineers.
Chris writes in his article that the time it takes to make new functionality is the smallest part of the cost of this functionality. He gives an example of how he did something for Yammer in 1 hour, and over the next 5 years, he spent 40 hours telling other engineers what it is and how it works. This means that the total for these conversations took at least 80 hours, because another engineer also spent his time on it.
')
The complexity can be divided into two types. The first kind of complexity is the number of functions that the system has. The second kind of complexity is over engineering when implementing a function. And the more features a product has, the more expensive its support and change. This kind of complexity can be reduced only in one way - to remove some function. Chris writes that in Yammer, after adding new functionality, they watch it for a while, and if it is not used and does not bring value, then it is removed. Moreover, they measure how all the functions on the site are used to assess what it is worth investing and what can be discarded.
The second kind of complexity is unnecessary complexity; it is treated only by a mature engineering approach. Instead of doing something “cool” (this disease is not only among Russian young engineers), you need to think about how to do something as simple as possible. Or simplify something that is already used in the project.
For example, in one of my projects there was a task scheduler, which was initially “sharpened under high loads”. It used a multithreaded architecture, and threads were used within each thread. Moreover, a multi-level procedure for rolling back tasks performed by the scheduler was designed. But sober reflection showed that the number of tasks that this scheduler performs is quite small, and a multi-level rollback greatly complicates the writing and support of the project, while all the same, all tasks were rolled back entirely in case of an error. We spent a week trying to simplify the planner, after which its code also decreased significantly and became much easier.
Several times I had to protect projects from the introduction of another “fast” message queue, when the number of messages per day did not exceed several thousand, and everything was fine on the database, which was already used in the project.
In several projects that we advised and on which a relational database was used, we got rid of MongoDB, greatly simplifying their support.
When a manager asks, “How long will it take to do such a thing?”, We must immediately think that this question is almost meaningless, because the time of support and refinement is many times longer than the time to create a new functionality.
It is clear that there are no projects with zero complexity, therefore in any project it is necessary to pay for the complexity. The only question is whether it is possible to do something with the project so that the complexity in it becomes less, and he brings as much money. This is complexity management - the task that a mature engineer solves.
And the questions that I put in the beginning of the article can be turned into just one: “How much do we overpay for complexity?” If this figure could be calculated in money, then this would be a “technical debt”.
Source: https://habr.com/ru/post/185488/
All Articles