Design Debt Metrics? -

the term design debt refers how debt incur everytime avoid doing right thing (like refactoring, removing duplication/redundancy) letting code quality deteriorate on time.

however, when people talk measuring design debt, people talk having sonar kind of dashboard. now, if talk sonar metrics apart complexity, think rest of metrics more tell code quality , not design quality. missing something?

are there tools measure (for eg. usage of patterns, or correct use of patterns, or matter suggest patterns used analysing code?) design quality. or still pretty art science?

i think way measure design debt use jdepend (if you're using java; there's dotnet equivalent).

just counting occurence of patterns not going helpful. i've seen codebases despite them being heavily pattern-infested, code still tightly-coupled badly written junk. seems me extremely difficult write tool distinguish helpful use of patterns counterproductive obfuscatory pattern-slinging.

anyway, jdepend measuring amount of coupling , independence in code. since thoughtful application of patterns supposed accomplish should useful design metric.

generally numbers jdepend need analysis because different parts of code should have different expectations kind of dependencies acceptable, it's not tool feed code , single number out grades whole codebase.

another useful metric cyclomatic complexity. measures number of different paths through code, it's indication of how gnarly , convoluted code is. code coverage tool cobertura generates cyclomatic complexity stats.

no set of metrics going give objective measure of codebase's suckitude. parts of code may need complicated, other parts have reason being dependent or otherwise coupled, , code may not matter if it's badly-written junk. can find tools can use check against expectations in order decide problems may be.