Evaluate your technical debt with Sonar(sonar.codehaus.org)
sonar.codehaus.org
Evaluate your technical debt with Sonar
http://sonar.codehaus.org/evaluate-your-technical-debt-with-sonar/
2 comments
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.
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.
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.
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 ;-).
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
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
Four good ideas ! you could have added another point to this ideal list :
5.Number of open bugs in production environment
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...
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...