This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
i am looking for a way to measure software system with metrics to (partly!) estimate maintainability (especially of software architecture). i know that one should never look onto metrics only because even if put together they most likely will never be able to express the whole spectrum of software complexity. regarding this the problem i experienced is that looking at the metrics itself one always finds a way to make them pass perfectly but looking closer as a human system could still be real crap.
what i look for is some metrics which can show hints or symptoms that something is going wrong (similar to smells). especially interesting to me is which metrics are complementing each other and are good to be grouped together.
on package/subsystem level has anybody made experience with coupling metrics of Robert C.Martin? they look quite promising for expression of the complexity of dependencies is possible. has anybody used them in real/bigger projects? did respective values correlate to a good maintainable system?
all papers i read so far are too theoretically, use far too small projects and do not face real software project conditions (there are lots of other to be maintained artifacts like xml, sql, server pages, legacy modules etc.).
i think lot research has to be done to get software complexity "better" measureable as nowadays. in my opinion this is one of the reasons why software quality and maintainability is often poor. or maybe it is not possible to measure software complexity at all...?
This was supposed to be one valuable application of McCabe's Cyclometric Complexity. A friend wrote an analyzer for COBOL and did histograms of the modules in a large mainframe system. The complexity metric mapped well to the the gut feelings about which ones you didn't want to touch. It was also useful to see any big jumps in any direction, usually meaning somebody failed to see a simpler solution to a new requirement.
JDepends supports all of Martin's package metrics for free, and Lattix has an expensive tool for very cool graphical manipulation of the dependency measures.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi