How to use Tech Debt for development?
You’ve probably heard this phrase, “We’ll refactor it later”, what do you feel with that?. Some people don’t trust this statement, so they…
You’ve probably heard this phrase, “We’ll refactor it later”, what do you feel with that?. Some people don’t trust this statement, so they don’t believe in that promise at all.
And what do you think are the underlying reasons of this feeling?
The Tech debt concept is not what majority of people think. Tech Debt is a tool, and as any tool in software has trade-offs.
People tend to think that Tech Debt is something bad, something to avoid, because we have been taught that Tech Debt means to do a poor quality work.
If you cannot read the full story, this is the friend’s link.
Tech debt is not to do a bad job, tech debt is a tool you have as a software developer, engineer, architecture, crafter (called it as you want) to solve the problem you have in front of you to get a significant short-term benefit.
There are a lot of types of tech debt, but the one that better applies for the sentence “We will refactor it later” is the “Prudent deliberate” Tech Debt.
Prudent deliberate
An example of this type of tech debt can be summarized as:
We must ship now and deal with consequences
Martin Fowler Tech Debt Quadrant
The sentence “We will refactor it later” could be really crucial, and the reason is the nature of Tech Debt.
The first definition of the term done by Ward Cunningham was related to this, you are selecting one option even if you know it is not the best one right now because you have another much bigger benefit in front of you and time is crucial.
It’s like when you need to buy a house, but you don’t have the money now, but you have a good job and you can afford a loan.
You know that you will pay more money after the loan is completed but in the other hand you can become independent, create a family, live alone, etc.
Something that right now has a major benefit, although you will pay more for the house in 20 years.
The point of this sentence is the promise of paying the debt, if you are lying, and you don’t pretend to pay the debt, or if you just don’t pay the debt, you will be in troubles in the future.
And why in real life great majority of people pay the debt, because we are forced to pay it, if not there will be eviction notices and the law will go against us.
In Software Development, when someone says “We will refactor it later” and another person replies you will not do it. We are just showing that in our organization or team, we don’t have a way to be sure tech debt will be paid. The only thing that makes the debt to be paid is the “word” of one person.
If we still think that this will not be solved in the near future even if we know that it must be solved, then we are admitting that we don’t know how to work with Prudent Tech Debt.
Then why do we push people for fixing prudent tech debt in the exact moment it was generated, because we don’t trust them.
Why don’t we trust them?.
Because we don’t trust in the way they work, that in fact is the way we work inside the team.
If I know that in the team we care about tech debt, we managed it, then I can take consciously the decision of creating Tech Debt.
What I’ve seen is that there are a lot of people that avoid completely the tool (Tech Debt), you cannot use tech debt at all because everything needs to be “perfect” the first time.
Perfect is the enemy of good, and this behavior only delays delivery much more. It’s naive to think that Tech Debt can be avoided.
The whole refactoring idea is about paying tech debt at the correct moment, when you know what to do, and you know that needs to be done.
Refactoring is the process of restructuring code, while not changing its original functionality.
wikipedia
Refactoring has a lot of sense in Prudent Inadvertent tech debt, because when we know now how to do it, we should go and pay the debt.
But refactoring is also for prudent deliberate tech debt, because we need to pay the loan when the benefit of taking that loan is in our hands and at that moment we can plan to pay the debt in the best way.
How to manage Tech Debt in a team?
The key part here is in a team, tech debt is a company problem that needs to be managed inside teams. Teams need to find ways to solve this, that is part of the Engineering problems related to Software.
Leave the campground cleaner than you found it.
Boy Scout Rule
Refactor mercilessly to keep the design simple as you go and to avoid
needless clutter and complexity.
The Refactor Mercilessly principle
Batman is a hero that helps people when the bat signal appears in the sky, emergencies happen all the time when you are a product team, or a DevOps team. Batman role is perfect to work when we have too much tech debt.
Bat-person role
Technical huddles are known by many names, tech huddle, dev huddle, dev meeting or daily huddle. These are all nothing but quick discussions amongst the team members to talk about design approaches, resolve technical blockers etc. They can also be used to do group code reviews and code walkthroughs.
Tech huddles
For all of these team approaches, it’s key to have agreements inside the team to favor refactoring:
Avoid feature branches, because working in isolation is against refactoring
Plan how to solve the tech debt
So next time in your team someone tells you that if you don’t do it now right it will not be done, or even if you feel that way, sits with your team to talk about why you are not managing Tech Debt.