Managing Technical Debt
Managing Technical Debt
Managing Technical Debt
Managing Technical Debt
Managing Technical Debt
Managing Technical Debt
January 2024
Technical debt is the concept of accruing debt to satisfy a short-term goal, however, that debt is required to be paid off as soon as possible. Much the same as applying for credit to make a short-term gain, a car, or a house, but that debt needs to be repaid over a period of time typically agreed by both parties within a legally binding contract.
Technical debt in software is required to be paid off, but in many circumstances, debt is often forgotten, and debt is often accrued to an unmanageable size.
Circumstances require us to move fast, a pressure applied deriving from the opportunity to enhance the lives of users, to bring them features which are high on the request list.
As an engineering manager I want to set a culture within the team of being prudent. Prudent in how to write and design the code and features, and prudent in how we manage our technical debt. I am not certain you are going to buy a new car with a loan and refuse to make your monthly payments, you enter a contract, and I expect most people to honour that contract. I feel the same way about technical debt. Acknowledge it exists, acknowledge it is unrealistic to never have any technical debt, but importantly acknowledge that as an engineer, it is expected you are prudent with the debt you accrue and track so you can repay as soon as you can schedule it.
This brought me to look at the Technical Debt Quadrant by Martin Fowler. The quadrant accounts for distinctions between prudent and reckless debt and the quadrant is completed by the addition of inadvertent and deliberate.
Technical debt is the concept of accruing debt to satisfy a short-term goal, however, that debt is required to be paid off as soon as possible. Much the same as applying for credit to make a short-term gain, a car, or a house, but that debt needs to be repaid over a period of time typically agreed by both parties within a legally binding contract.
Technical debt in software is required to be paid off, but in many circumstances, debt is often forgotten, and debt is often accrued to an unmanageable size.
Circumstances require us to move fast, a pressure applied deriving from the opportunity to enhance the lives of users, to bring them features which are high on the request list.
As an engineering manager I want to set a culture within the team of being prudent. Prudent in how to write and design the code and features, and prudent in how we manage our technical debt. I am not certain you are going to buy a new car with a loan and refuse to make your monthly payments, you enter a contract, and I expect most people to honour that contract. I feel the same way about technical debt. Acknowledge it exists, acknowledge it is unrealistic to never have any technical debt, but importantly acknowledge that as an engineer, it is expected you are prudent with the debt you accrue and track so you can repay as soon as you can schedule it.
This brought me to look at the Technical Debt Quadrant by Martin Fowler. The quadrant accounts for distinctions between prudent and reckless debt and the quadrant is completed by the addition of inadvertent and deliberate.
I strive to become deliberate and prudent “We’ve assessed the risks of this design and are going to roll it out, knowing the consequences we'll have to deal with down the line.”.
Now, we know that variables do not allow us to know all the risks ahead of time.
Circumstances occur where a team or engineer will not know what those risks are until the code has been written, falling into inadvertent and prudent “We missed some problems during development but we’re keeping on top of them as they arise and learning from our mistakes.” I value this very highly. Let me explain…
Although we want to be all knowing ahead of time i.e. deliberate and prudent, it is not a realistic scenario we can expect of our teams, however, striving for it gives us a goal to progress towards. What I value so highly is a team that has the competence to be prudent about what was missed during development, tracking what was missed, communicating what was missed and is motivated to schedule addressing what was missed as soon as possible.
In addition, what typically can go overlooked is the “learning from our mistakes” part, conducting a retrospective helps tackle that and helps us grow as an elite engineering team, by sharing knowledge and giving the team the opportunity to grow as a collective unit. Teamwork and collaboration I also value very highly.
But what if you don’t do any of this? Where does that fall into the quadrant?
One word “Reckless”... you are now a reckless engineering team, wow sounds harsh right?
Don’t take it personally, this happens frequently and it is all part of our growth to becoming an elite engineering team. It is a team problem to develop a prudent culture. “Reckless” can be associated with a decision or a business pressure or some other circumstance which we don’t control and have limited ability to influence. We place this into the inadvertent reckless section of the quadrant. “Everything will probably go fine!” [Things end up not going fine].”. This is a tough one and requires to be explored deeply to understand why.
I found myself to be in this situation last year in 2023. Inadvertent meaning we make mistakes and are reckless by not being prudent in tracking and planning to address them down the line.
I strive to become deliberate and prudent “We’ve assessed the risks of this design and are going to roll it out, knowing the consequences we'll have to deal with down the line.”.
Now, we know that variables do not allow us to know all the risks ahead of time.
Circumstances occur where a team or engineer will not know what those risks are until the code has been written, falling into inadvertent and prudent “We missed some problems during development but we’re keeping on top of them as they arise and learning from our mistakes.” I value this very highly. Let me explain…
Although we want to be all knowing ahead of time i.e. deliberate and prudent, it is not a realistic scenario we can expect of our teams, however, striving for it gives us a goal to progress towards. What I value so highly is a team that has the competence to be prudent about what was missed during development, tracking what was missed, communicating what was missed and is motivated to schedule addressing what was missed as soon as possible.
In addition, what typically can go overlooked is the “learning from our mistakes” part, conducting a retrospective helps tackle that and helps us grow as an elite engineering team, by sharing knowledge and giving the team the opportunity to grow as a collective unit. Teamwork and collaboration I also value very highly.
But what if you don’t do any of this? Where does that fall into the quadrant?
One word “Reckless”... you are now a reckless engineering team, wow sounds harsh right?
Don’t take it personally, this happens frequently and it is all part of our growth to becoming an elite engineering team. It is a team problem to develop a prudent culture. “Reckless” can be associated with a decision or a business pressure or some other circumstance which we don’t control and have limited ability to influence. We place this into the inadvertent reckless section of the quadrant. “Everything will probably go fine!” [Things end up not going fine].”. This is a tough one and requires to be explored deeply to understand why.
I found myself to be in this situation last year in 2023. Inadvertent meaning we make mistakes and are reckless by not being prudent in tracking and planning to address them down the line.
My goal moving forward was to improve the prudent culture within the team. We’re moving fast and I do not like to recklessly move fast, let’s move fast with prudence and we should see a much safer outcome.
My goal moving forward was to improve the prudent culture within the team. We’re moving fast and I do not like to recklessly move fast, let’s move fast with prudence and we should see a much safer outcome.
Approaching three months, we managed to shift towards an inadvertent prudent culture within the team. Confidence has grown and we’re in much better shape.
Approaching three months, we managed to shift towards an inadvertent prudent culture within the team. Confidence has grown and we’re in much better shape.
