Evaluate your technical debt with Sonar (opens in new tab)

(sonar.codehaus.org)

27 pointsfarnulfo17y ago7 comments

7 comments

7 comments · 2 top-level

jimrandomh17y ago· 3 in thread

Software does not have a sense of elegance, and short of a strong AI, it cannot ever have a sense of elegance. The kind of technical debt that matters is mismatches between program abstractions and target domain abstractions. What this does is more like using a spell checker to determine how close a book is to being ready to publish - fundamentally misguided at best.

yellowbkpk17y ago

I wish you could flesh that out a little and forward it on to the folks ensuring the software we write at work is "high quality." I keep telling them that metrics and unit tests don't make a quality system, a good design and bug fixing does.

freddy_mallet17y ago

But applications with good design always have good metrics and unit tests ... The technical debt can't say that an application has a good design but it can say that it has a poor one.

freddy_mallet17y ago

I don't know any spell checker which is able to give you the amount of duplicated code, code coverage by unit tests, ditribution of complexity, ratio of documented api and so forth ;-).

DenisM17y ago· 2 in thread

Nice. I would like to see inclusion of the following metrics:

1. Class coupling - amount of time it takes to grok the code

2. Build time (full, typical partial etc) - amount of time developer is twiddling his tumbs

3. Time between checkin, integration tests and end-user tests - amount of time code spent being created but not used, aka "waste" per The Toyota Way

4. Referential loops in layering diagram - amount of problems that need to be overcome to start refactoring

freddy_mallet17y ago

Four good ideas ! you could have added another point to this ideal list : 5.Number of open bugs in production environment

DenisM17y ago

Yes, I was hoping to create a conversation here with this seeder list. There doesn't seem to be much interest here though. :-)

BTW, number of bugs should probably be weighted with number of incidents for each bug and its impact. The mere thought of this makes me rethink my design - how will know the number of incidents? Should I instrument my code to download "bug signatures" and report back the findings? For a web app it seem a straightforward thing to do. How would I do this for desktop/iphone app? I could proably send down some script code to walk over the local storage to look for problems. How about UX bugs though? Should I log UX interactions into a local database and send down queries as well? Hm...

j / k navigate · click thread line to collapse

7 comments

7 comments · 2 top-level

jimrandomh17y ago· 3 in thread

yellowbkpk17y ago

freddy_mallet17y ago

But applications with good design always have good metrics and unit tests ... The technical debt can't say that an application has a good design but it can say that it has a poor one.

freddy_mallet17y ago

I don't know any spell checker which is able to give you the amount of duplicated code, code coverage by unit tests, ditribution of complexity, ratio of documented api and so forth ;-).

DenisM17y ago· 2 in thread

Nice. I would like to see inclusion of the following metrics:

1. Class coupling - amount of time it takes to grok the code

2. Build time (full, typical partial etc) - amount of time developer is twiddling his tumbs

3. Time between checkin, integration tests and end-user tests - amount of time code spent being created but not used, aka "waste" per The Toyota Way

4. Referential loops in layering diagram - amount of problems that need to be overcome to start refactoring

freddy_mallet17y ago

Four good ideas ! you could have added another point to this ideal list : 5.Number of open bugs in production environment

DenisM17y ago

Yes, I was hoping to create a conversation here with this seeder list. There doesn't seem to be much interest here though. :-)

j / k navigate · click thread line to collapse