71–80 of 122 posts
Earlier quoted context omitted.
It's like financial debt, but we can can't tell you what the interest rate is.
or if you'll ever have to pay it back. Just because you have some tech debt doesn't mean you'll actually have to ever deal with it.
Earlier quoted context omitted.
or if you'll ever have to pay it back. Just because you have some tech debt doesn't mean you'll actually have to ever deal with it.
I was going to say the opposite, just because you'll "pay it off later" doesn't mean you're not paying for it now, with every single change taking longer than necessary.
> But technical debt becomes a problem when it gets out of control. Accumulating technical debt consists in piling up hacks on a piece of code, making it harder and harder to maintain. Every incremental change requires an intense reflexion and is more and more likely to cause regressions. Can anyone explain to me what reflexion means in this context?
The best analogy for technical debt is debt - that is where it got the name from! Just like financial debt, technical debt is not necessary a bad thing, but a tool - and something to manage, control and track. And just like financial debt, taking out too much technical debt without paying it back can crush you. There is nothing wrong with taking out a mortgage (and thus getting into debt) to buy a house - you just ne…
That kind of debt, right?
But wait there's more! I forgot to mention that even if you walk away you get to keep what you bought on credit, without any further payment of any kind and it continues working in its current state, forever - you just can't improve or renovate it if you walk away from the debt.¹
That kind of debt, right? If so then perfect analogy.
-
¹ literal lie though, yes you can. you can totally still improve it real quick. I'm afraid I'll have to add $150,000 to your technical debt though, which you can walk away from any time. still want this real quick $50 change though? It might be $50 but it's $150,000 in debt though.
Technical Debt is a bullshit term for people who want to get away with not finishing their work and still want to sound like they are reasonable.
You do everything in your power to explain the compromises that were made to the CTO and the CEO, and they weigh their options and determine that they want to keep duct taping things together as fast as possible to keep making more of these quick sales.
Building things "right" the first time is a luxury that is rarely possible in the real world, I've found. Maybe if you are working at a big company like Google or Amazon? But from what I've seen, even the projects coming out of those companies are often deeply flawed and have have a plethora of issues when they are initially released.
The best analogy for technical debt is debt - that is where it got the name from! Just like financial debt, technical debt is not necessary a bad thing, but a tool - and something to manage, control and track. And just like financial debt, taking out too much technical debt without paying it back can crush you. There is nothing wrong with taking out a mortgage (and thus getting into debt) to buy a house - you just ne…
Most of what people call debt, though, is really just comprises. Which works, to me, as you can just say the code is too compromised. :)
Earlier quoted context omitted.
It's like financial debt, but we can can't tell you what the interest rate is.
or if you'll ever have to pay it back. Just because you have some tech debt doesn't mean you'll actually have to ever deal with it.
Earlier quoted context omitted.
I wonder if there was a time in history where financial debt was not well understood. This would have to be either before the invention of algebra, or possibly also during a time of very poor education.
> or possibly also during a time of very poor education. So, you mean today? The number of students that take on crippling amounts of student loans without truly understanding how it will affect them is staggering to me. The ease of obtaining credit before a person truly understands how devastating 20%+ interest rates are is also pretty telling. Financial debt is easy to get wrong, and is only compounded by the fact…
Or just large numbers. A valid strategy to invest a million will be worthless with just a dime. No matter what the silly myths of success say.
Earlier quoted context omitted.
The difference though is that financial debt is very easy to measure and quantify but technical debt is not. I like the Tetris analogy because that game has a type of debt that anyone who has played it can understand, yet is not as easily quantifiable as financial debt.
It's like financial debt, but we can can't tell you what the interest rate is.
Implementation technical debt (the code) makes it harder for devs to work in a given service, slows down velocity and increases the risk of bugs, but is at least contained to a given service and can be rewritten as a known quantity.
Architectural technical debt will crush your product or your stack, often quickly.