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.
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.