DEV Community

loading...

Discussion on: You Can’t Keep Building on a Broken System: Why Managing Technical Debt is So Important

Collapse
thawkin3 profile image
Tyler Hawkins Author

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

Collapse
sarafian profile image
Alex Sarafian

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.