Technical duty like tetris
Winning is impossible. You just decide how fast to lose.
What is the next move?
Many people like Tetris, me too. I remember playing for the first time on my friend's Nintendo Game Boy. Perhaps that tune stuck in your head too. Tetris is not only one of the best games of all time, but also an excellent analogy for technical duty. It gives a general understanding of technical duty and its impact.
')
I'll tell you another story from personal experience, as my team reduced technical debt in some billing code and, at the same time, fixed a million dollar error per year .
First, tasks are simpler, on a low level of difficulty.
In software companies, product / project managers, along with developers, determine which code will be written and sent to customers in the next release. Completing a line in tetris is similar to the release of a function.
Complex functions are quite feasible almost without increasing technical debt.
The release of a complex function requires the completion of several lines .
Often, business needs (new features, new products) lead to compromises in the code (hacks, workarounds), so as not to delay the deadline. Or changes in product strategy are incompatible with the previous design, requiring additional efforts to migrate customers or support both "new" and "old" logic.
Small technical debt is normal and manageable.
Such scenarios create technical debt within the code. Hidden pass in Tetris is a technical debt.
Any code has technical debt. This is normal. You can continue to play with a few passes.
Buried in technical duty
Too much technical debt does not allow for a reasonable time to release a new function or correct an error.
This problem cannot be solved by adding new developers or, more dramatically, replacing existing ones. This is called a technical debt : at some point it will have to pay.
The repayment of technical debt makes you competitive. It keeps you in the game.
Game over
Like business management, in Tetris, complexity increases over time. Shapes move faster and harder to keep up.
As in business, it is impossible to win. No real finish line. The only question is how soon you lose.
Like a business, too many gaps in tetris lead to a loss.
Not so long ago, my team was instructed to update the billing / invoice logic in our product code to support new pricing plans, new payment processors, and improve the entire billing process as a whole. Some details were still being clarified, so we used this time to dive deep into the existing code in order to give more accurate estimates of the upcoming changes.
The main objective of this code was to go through the accounts of all customers, calculate each - and send information to the API for invoicing. The system was written with great care and well-intentioned - not so sloppy as inflexible. Monolithic function. No tests. Very few logs. Documentation was virtually absent. Some kind of inexplicable randomization occurred. The system was written more than five years ago by one of the founders. The only changes since then were made by one of the first employees who was already absent from the company.
Was there a problem at all? Invoices were billed. The company made money. There was no sign of a problem. All this spoke against refactoring, but we knew that big changes were coming: this function could not scale for our needs, and it would be much easier to move on if we simplified this part.
In one sprint, we reworked the function and added some much-needed logs. It was then that we found that we actually repaired it. Some of the accountants stopped at our desks and asked why the number of outgoing invoices had suddenly increased. The old code quietly fell off on a timer - and some clients were not processed. Strange randomization? She hid any models that could make it clear that some customer had not been invoiced. When we conducted the assessment, we counted the missing invoices for more than $ 1 million per year.
Although the story is completely true, the payment of technical debt does not always have such a dramatic effect. We were lucky.
Find the right balance of technical debt
I would like to give wise advice when you need to pay technical debt. Unfortunately, the answer is that it is difficult - and it always comes down to balance . You may have the cleanest, most well-tested code in the world, but not the customers. And on the contrary, your company can work in a really dirty code, but which pleases customers, and money flows like a river.
I can only say that both the owners of the product and the developers must understand the essence of technical debt and that it cannot be avoided forever. In the end, as in Tetris, here you can never win.
What is the next move?
Many people like Tetris, me too. I remember playing for the first time on my friend's Nintendo Game Boy. Perhaps that tune stuck in your head too. Tetris is not only one of the best games of all time, but also an excellent analogy for technical duty. It gives a general understanding of technical duty and its impact.
')
I'll tell you another story from personal experience, as my team reduced technical debt in some billing code and, at the same time, fixed a million dollar error per year .
First, tasks are simpler, on a low level of difficulty.
In software companies, product / project managers, along with developers, determine which code will be written and sent to customers in the next release. Completing a line in tetris is similar to the release of a function.
Complex functions are quite feasible almost without increasing technical debt.
The release of a complex function requires the completion of several lines .
Often, business needs (new features, new products) lead to compromises in the code (hacks, workarounds), so as not to delay the deadline. Or changes in product strategy are incompatible with the previous design, requiring additional efforts to migrate customers or support both "new" and "old" logic.
Small technical debt is normal and manageable.
Such scenarios create technical debt within the code. Hidden pass in Tetris is a technical debt.
Any code has technical debt. This is normal. You can continue to play with a few passes.
Buried in technical duty
Too much technical debt does not allow for a reasonable time to release a new function or correct an error.
This problem cannot be solved by adding new developers or, more dramatically, replacing existing ones. This is called a technical debt : at some point it will have to pay.
The repayment of technical debt makes you competitive. It keeps you in the game.
Game over
Like business management, in Tetris, complexity increases over time. Shapes move faster and harder to keep up.
As in business, it is impossible to win. No real finish line. The only question is how soon you lose.
Like a business, too many gaps in tetris lead to a loss.
Million dollar bug
Not so long ago, my team was instructed to update the billing / invoice logic in our product code to support new pricing plans, new payment processors, and improve the entire billing process as a whole. Some details were still being clarified, so we used this time to dive deep into the existing code in order to give more accurate estimates of the upcoming changes.
The main objective of this code was to go through the accounts of all customers, calculate each - and send information to the API for invoicing. The system was written with great care and well-intentioned - not so sloppy as inflexible. Monolithic function. No tests. Very few logs. Documentation was virtually absent. Some kind of inexplicable randomization occurred. The system was written more than five years ago by one of the founders. The only changes since then were made by one of the first employees who was already absent from the company.
Was there a problem at all? Invoices were billed. The company made money. There was no sign of a problem. All this spoke against refactoring, but we knew that big changes were coming: this function could not scale for our needs, and it would be much easier to move on if we simplified this part.
In one sprint, we reworked the function and added some much-needed logs. It was then that we found that we actually repaired it. Some of the accountants stopped at our desks and asked why the number of outgoing invoices had suddenly increased. The old code quietly fell off on a timer - and some clients were not processed. Strange randomization? She hid any models that could make it clear that some customer had not been invoiced. When we conducted the assessment, we counted the missing invoices for more than $ 1 million per year.
Payout doesn't always pay off
Although the story is completely true, the payment of technical debt does not always have such a dramatic effect. We were lucky.
Find the right balance of technical debt
I would like to give wise advice when you need to pay technical debt. Unfortunately, the answer is that it is difficult - and it always comes down to balance . You may have the cleanest, most well-tested code in the world, but not the customers. And on the contrary, your company can work in a really dirty code, but which pleases customers, and money flows like a river.
I can only say that both the owners of the product and the developers must understand the essence of technical debt and that it cannot be avoided forever. In the end, as in Tetris, here you can never win.
Source: https://habr.com/ru/post/443896/
All Articles