I disagree with your definition of technical debt about being something that derives from shortcuts or any other her practice. Technical debt exists just because you code or just because you exercise software engineering. No matter how well you code it will be inevitably outdated, as code or as technology and it will require "maintenance"or replacement. To your house analogy, it just gets old with time.
Not to dismiss what you say. Shortcuts or not, good or bad code, all affect the impact and longevity like with the choices in material and design with the house analogy or any other building.
Because if this important difference, the term debt is not appreciated by many because it adds a sort of guilt no matter how well the engineers did. You don't build a house and think that you buy a debt right?, so why would you with software?
I hope, you find this insight interesting and gives a bit of a different perspective. Just to be clear,. I don't disagree with the rest of the article. I also think that sometimes bad choices are necessary but it is also necessary not to forget about them.
Hey Alex, thanks for your comment. I think we're actually agreed, both on the definition of tech debt and also in regards to the need to take on tech debt from time to time. :)
Technical debt can take the form of poor design decisions, much-needed refactorings, technology upgrades, and outstanding bugs.
I'm using the definition of technical debt as commonly agreed upon:
Also like financial debt, there are wise and unwise ways to take on and manage technical debt.
The Martin Fowler article I linked to also discusses the tech debt quadrant and in what ways it can be wise or unwise to take on tech debt, so that's some good further reading if you're interested: martinfowler.com/bliki/TechnicalDe...
I like Fowler's definition the best because he also makes a distinction about how it was produced.
My problem and the reason for my comment is that although no definition excludes the fact that debt is produced by just coding or when choosing a technology, all examples usually focus on bad/silly/fast choices.
Too a certain point, people refer to technical tebt, badly and don't understand the fundamentals that are not even specific to software engineering. And to help your post being misused like that one more time, I commented with a correction because the rest was good.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I disagree with your definition of technical debt about being something that derives from shortcuts or any other her practice. Technical debt exists just because you code or just because you exercise software engineering. No matter how well you code it will be inevitably outdated, as code or as technology and it will require "maintenance"or replacement. To your house analogy, it just gets old with time.
Not to dismiss what you say. Shortcuts or not, good or bad code, all affect the impact and longevity like with the choices in material and design with the house analogy or any other building.
Because if this important difference, the term debt is not appreciated by many because it adds a sort of guilt no matter how well the engineers did. You don't build a house and think that you buy a debt right?, so why would you with software?
I hope, you find this insight interesting and gives a bit of a different perspective. Just to be clear,. I don't disagree with the rest of the article. I also think that sometimes bad choices are necessary but it is also necessary not to forget about them.
Hey Alex, thanks for your comment. I think we're actually agreed, both on the definition of tech debt and also in regards to the need to take on tech debt from time to time. :)
I'm using the definition of technical debt as commonly agreed upon:
The Martin Fowler article I linked to also discusses the tech debt quadrant and in what ways it can be wise or unwise to take on tech debt, so that's some good further reading if you're interested: martinfowler.com/bliki/TechnicalDe...
I like Fowler's definition the best because he also makes a distinction about how it was produced.
My problem and the reason for my comment is that although no definition excludes the fact that debt is produced by just coding or when choosing a technology, all examples usually focus on bad/silly/fast choices.
Too a certain point, people refer to technical tebt, badly and don't understand the fundamentals that are not even specific to software engineering. And to help your post being misused like that one more time, I commented with a correction because the rest was good.