Timeline for How can I quantify the amount of technical debt that exists in a project?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 11, 2022 at 9:00 | comment | added | Tulains Córdova | 2/2 An example could be a codebase that parses dates and does date arithmetic without using the language's built-in date-time library. This is hard to measure, although it can somehow affect the quality metrics regarding complexity, cohesion, etc. | |
| Feb 11, 2022 at 9:00 | comment | added | Tulains Córdova | 1/2 Aren't these metrics the same ones used to measure code quality? Is it true that code quality is inversely proportional to technical debt? If so, any answer to the question "How do I measure code quality?" would also answer "How do I measure technical debt?"I believe technical debt can go beyond mere code quality metrics and include sub-utilizing the capabilities of current technology. | |
| Oct 2, 2012 at 13:26 | history | edited | Thomas Owens♦ | CC BY-SA 3.0 |
added 182 characters in body
|
| Sep 16, 2012 at 14:10 | comment | added | Only You | @ErikDietrich I would suggest to put that "kind of number" to indicate cost in the following manner: because our code base is 'this bad' it is taking 'this long' to implement 'this change', consecuently our 'time to market' (or time to delivery) is 'this'. 'this bad' would be your code metric, whichever is best for your particular needs, 'this long' would be, and this is my suggestion, your technical debt cost because you could put numbers on it as time and money; if implementation effort takes 'this long' and dev rate is $/hour, you could find out how long and how much the changes cost. | |
| Feb 21, 2012 at 14:21 | comment | added | Thomas Owens♦ | @MaR I don't see how you can cheat any of the metrics I provided. Perhaps code coverage can be gamed, but any good process should include reviews of the tests to ensure they are useful and valid. Perhaps code can be duplicated by removing method calls and copy/pasting the block of code. But you can't game coupling, cohesion, Halstead complexity measures, or cyclomatic complexity. | |
| Feb 21, 2012 at 14:19 | comment | added | MaR | @Thomas Owens: agreed, but almost any metric alone can be cheated. If used right and honestly, "TODO metric" provides cheap overview what code is actually missing or should be changed (=invisible debt for code-only based metrics). | |
| Feb 21, 2012 at 12:49 | comment | added | Thomas Owens♦ | @Mar That assumes that you properly use these and aren't gaming them for your advantage. Want some extra time to clean up the code base, just add these comments where they aren't appropriate. Don't care about the codebase, just remove them from where they should be. Comments can lie, code can't. | |
| Feb 21, 2012 at 12:31 | comment | added | MaR | Another simple metric I'd add to the list is number of TODO/HACK/WTF? comments in a codebase... | |
| Feb 21, 2012 at 7:45 | vote | accept | Erik Dietrich | ||
| Feb 20, 2012 at 20:17 | comment | added | Thomas Owens♦ | @ErikDietrich You might be able to, but I probably wouldn't quantify that value. Perhaps an "executive summary" style report on what your metric tools tell you, with respect to changes over time, would be more appropriate. | |
| Feb 20, 2012 at 20:04 | comment | added | Erik Dietrich | I currently use NDepend (ndepend.com), CodeRush and VS code metrics to keep an eye on the metrics you mention (with the exception of the Halstead measures, which I'll look into further). I was thinking I might use some amalgamation of these metrics to attempt to put some kind of number on a given code element that would roughly indicate, at a glance, how costly it was to ongoing development. | |
| Feb 20, 2012 at 19:42 | history | answered | Thomas Owens♦ | CC BY-SA 3.0 |