March 15, 2019 at 18:35Technical debt like tetris
- Transfer
Winning is not possible. You only decide how fast to lose
What is the next move?
Many people like tetris, me too. I remember playing my friend for the first time on the 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 a great analogy for technical debt. It provides a general understanding of technical debt and its impact.
I’ll tell you a story from personal experience how my team reduced its technical debt in some kind of billing code and at the same time corrected the error by a million dollars a year .
At first, tasks are simpler, at a low level of complexity.
In software companies, product / project managers together with developers determine which code will be written and sent to customers in the next release. Completing a line in tetris is like releasing a function.
Complex functions are quite feasible with almost no increase in technical debt.
The production 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 overdue the deadline. Or changes in the product strategy are incompatible with the previous design, requiring additional efforts to migrate customers or support both the "new" and the "old" logic.
Small technical debt is normal and manageable.
Similar scenarios create technical debt within the code. A hidden pass in Tetris is a technical duty.
Any code has a technical duty. This is normal. You can continue to play with a few passes.
Buried in technical debt.
Too much technical debt does not allow for a reasonable time to release a new function or fix a bug.
This problem cannot be solved by adding new developers or, more dramatically, replacing existing ones. This is called technical debt : at some point it will have to be paid.
Paying off your technical debt makes you competitive. It keeps you in the game.
Game over
Like managing a business, in Tetris, complexity increases over time. Shapes move faster and are harder to keep up with.
As in business, it is impossible to win here. There is no real finish line. The only question is how soon will you lose.
Like 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, a new payment processor, and to improve the entire billing process as a whole. Some details were still being clarified, so we used this time to dive deep into existing code to give more accurate estimates of upcoming changes.
The main task of this code was to go through the accounts of all customers, calculate each one, and send information to the API for invoicing. The system was written with great care and good intentions - not so much sloppy as inflexible. Monolithicfunction. No tests. Very few logs. There was practically no documentation. There was some inexplicable randomization. One of the founders wrote the system more than five years ago. 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 were no signs of a problem. All this spoke against refactoring, but we knew that big changes were coming: this function could not be scaled for our needs, and it would be much easier to move on if we simplified this part.
In one sprint, we redesigned the function and added some much-needed logs. Then we found thatactually repaired. One of the accountants stopped at our desks and asked why the number of outgoing invoices unexpectedly increased. The old code quietly fell off on the timer - and some clients were not processed. Strange randomization? She hid any models that could make it clear that some client was not issued an invoice. When we carried out the assessment, we calculated the missing invoices by more than $ 1 million per year.
Although the story is completely true, paying off technical debt does not always have such a dramatic effect. We were lucky.
Finding the right balance of technical debt
I would like to give wise advice when you need to pay off 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 have clients. And vice versa, your company can work in really dirty code, but which pleases customers, and money flows like a river.
I can only say that both product owners and 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 my friend for the first time on the 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 a great analogy for technical debt. It provides a general understanding of technical debt and its impact.
I’ll tell you a story from personal experience how my team reduced its technical debt in some kind of billing code and at the same time corrected the error by a million dollars a year .
At first, tasks are simpler, at a low level of complexity.
In software companies, product / project managers together with developers determine which code will be written and sent to customers in the next release. Completing a line in tetris is like releasing a function.
Complex functions are quite feasible with almost no increase in technical debt.
The production 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 overdue the deadline. Or changes in the product strategy are incompatible with the previous design, requiring additional efforts to migrate customers or support both the "new" and the "old" logic.
Small technical debt is normal and manageable.
Similar scenarios create technical debt within the code. A hidden pass in Tetris is a technical duty.
Any code has a technical duty. This is normal. You can continue to play with a few passes.
Buried in technical debt.
Too much technical debt does not allow for a reasonable time to release a new function or fix a bug.
This problem cannot be solved by adding new developers or, more dramatically, replacing existing ones. This is called technical debt : at some point it will have to be paid.
Paying off your technical debt makes you competitive. It keeps you in the game.
Game over
Like managing a business, in Tetris, complexity increases over time. Shapes move faster and are harder to keep up with.
As in business, it is impossible to win here. There is no real finish line. The only question is how soon will you lose.
Like 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, a new payment processor, and to improve the entire billing process as a whole. Some details were still being clarified, so we used this time to dive deep into existing code to give more accurate estimates of upcoming changes.
The main task of this code was to go through the accounts of all customers, calculate each one, and send information to the API for invoicing. The system was written with great care and good intentions - not so much sloppy as inflexible. Monolithicfunction. No tests. Very few logs. There was practically no documentation. There was some inexplicable randomization. One of the founders wrote the system more than five years ago. 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 were no signs of a problem. All this spoke against refactoring, but we knew that big changes were coming: this function could not be scaled for our needs, and it would be much easier to move on if we simplified this part.
In one sprint, we redesigned the function and added some much-needed logs. Then we found thatactually repaired. One of the accountants stopped at our desks and asked why the number of outgoing invoices unexpectedly increased. The old code quietly fell off on the timer - and some clients were not processed. Strange randomization? She hid any models that could make it clear that some client was not issued an invoice. When we carried out the assessment, we calculated the missing invoices by more than $ 1 million per year.
Payout doesn't always pay off
Although the story is completely true, paying off technical debt does not always have such a dramatic effect. We were lucky.
Finding the right balance of technical debt
I would like to give wise advice when you need to pay off 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 have clients. And vice versa, your company can work in really dirty code, but which pleases customers, and money flows like a river.
I can only say that both product owners and 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.