In the Complexity Map, a slightly similar approach, a treemap is used to visualize the code's namespace hierarchy in a 2d-landscape. Results from code metric tools are layed out in the treemap, either for individual metrics (e.g. cyclomatic complexity) or for aggregated metrics (anthing that influences team productivity; e.g. errors that are not logged). Due to the Prefuse-based seamless zooming, combined with drill down functionality, it's really easy to visualize and investigate hotspots in extremely large codebases.
The website contains some more background and a nice interactive demo. If you have the patience to wait for the applet to load, I'll guarantee you you'll like it.
Disclaimer: I am the author of this tool. The website mentions commercial interest, but to be honest: there's hardly any. I've found that the concept is just too difficult to sell over the web, so I'll probably open source it soon.
Excellent points; it's often hard to judge when code is too complicated and whether the refactoring is moving in the right direction. My project to visualize technical dept aims help discussions in this area. See:
"A designer knows he has achieved perfection, not when there is nothing left to add, but when there is nothing left to take away." Antoine de Saint-Exupery
I've been working on a tool to visualize technical debt in large software systems over the past year (see http://complexitymap.com/ .
From a supplier-side (e.g. IT-development groups, large system integrators), there is very little interest in tools which visualize problems in code, to use a big understatement. Most enterprise code is not worth looking at, so these organizations tend to keep their client out of the kitchen and manage the perception that everything is going fine. Usually at client/buyer-side, the relevance is missed, since the main question they're asking is: does it work yet? When talking to the client's contract management group however, could leads to a more interesting discussion; why would a company have to accept software which clearly contains flaws in thinking or programming?
Some time ago I read a book that is used in first year classes of philosophy at the University of Leiden in the Netherlands. It is called "Reason, Truth and History" and is written by Hilary Putnam, (ISBN 0-521-29776-1). It deals with the issue whether it would be possible for humans to just be "Brains in a Vat" ánd be aware of that. Consider the possibility that you are just a Brain in a Vat connected to a computer that projects the images of all that you see/sense as stimulating electronic impulses to your nerves. This of course is completely the idea that was used for the film the Matrix. Although complete explaination goes beyond this post some of you might find it interesting to read why Putman argues we can not possibily detect we're in such a situation. He explains the statement that we're Brains in a Vat is self-refuting and thus can't be true...
Slashdot Mirror
The QUINT-2 model (extended from ISO 9126) is a model to discuss various aspects of software product quality, see: http://www.serc.nl/quint-book/
Check the Quint-2 browser if you like a nice visual representation: http://complexitymap.com/quint2/
Hope this helps. Don't hesitate if you have additional questions.
In the Complexity Map, a slightly similar approach, a treemap is used to visualize the code's namespace hierarchy in a 2d-landscape. Results from code metric tools are layed out in the treemap, either for individual metrics (e.g. cyclomatic complexity) or for aggregated metrics (anthing that influences team productivity; e.g. errors that are not logged). Due to the Prefuse-based seamless zooming, combined with drill down functionality, it's really easy to visualize and investigate hotspots in extremely large codebases.
The website contains some more background and a nice interactive demo. If you have the patience to wait for the applet to load, I'll guarantee you you'll like it.
Disclaimer: I am the author of this tool. The website mentions commercial interest, but to be honest: there's hardly any. I've found that the concept is just too difficult to sell over the web, so I'll probably open source it soon.
Excellent points; it's often hard to judge when code is too complicated and whether the refactoring is moving in the right direction. My project to visualize technical dept aims help discussions in this area. See:
http://complexitymap.com/
"A designer knows he has achieved perfection, not when there is nothing left to add, but when there is nothing left to take away."
Antoine de Saint-Exupery
I agree, there's definitely a lot of truth there.
I've been working on a tool to visualize technical debt in large software systems over the past year (see http://complexitymap.com/ .
From a supplier-side (e.g. IT-development groups, large system integrators), there is very little interest in tools which visualize problems in code, to use a big understatement. Most enterprise code is not worth looking at, so these organizations tend to keep their client out of the kitchen and manage the perception that everything is going fine. Usually at client/buyer-side, the relevance is missed, since the main question they're asking is: does it work yet? When talking to the client's contract management group however, could leads to a more interesting discussion; why would a company have to accept software which clearly contains flaws in thinking or programming?
I did not experience this behavior, nor did several other readers. Please mod parent down.
Some time ago I read a book that is used in first year classes of philosophy at the University of Leiden in the Netherlands. It is called "Reason, Truth and History" and is written by Hilary Putnam, (ISBN 0-521-29776-1). It deals with the issue whether it would be possible for humans to just be "Brains in a Vat" ánd be aware of that. Consider the possibility that you are just a Brain in a Vat connected to a computer that projects the images of all that you see/sense as stimulating electronic impulses to your nerves. This of course is completely the idea that was used for the film the Matrix. Although complete explaination goes beyond this post some of you might find it interesting to read why Putman argues we can not possibily detect we're in such a situation. He explains the statement that we're Brains in a Vat is self-refuting and thus can't be true...