The book in one sentence
A short, modest and dryly written book with some brilliant new concepts and a lot of too easy solutions which is worth reading because of the brilliant ideas.
How did it come about that I read a book about software metrics? I will have to digress somewhat before answering the question. There is a strong common believe in software engineering that software metrics are a dangerous tool, especially in the hand of Joel's bright young management consultant. But sharp tools that you can use to harm people can often be used to get things done.
What if our pre-pre-pre-(...)-pre-ancestors had condemned the use of a knife just because some of their brethren ran around slitting up other peoples throats? So I wanted to find out more about software metrics to decide for myself if they provide a new, sharp tool, or just a deadly weapon to be utilized by management consultants. But even with a lot of google magic I couldn't find a good critical introduction to software metrics anywhere on the web.
Then a few weeks ago an IT consultant asked about software metrics in a forum about software quality assurance at xing. I answered by reiterating the "dangerous tool" conception, emphasizing that software metrics alone can't be used as a quality assessment, which obviously didn't satisfy our questioner. Another member recommended "Object-Oriented Metrics In Practice", praising especially the solution oriented style of the book. So I figured that I should educate myself on the topic before broadcasting my opinion.
The first good point the book makes is that software metrics can show only structural points of interest, but not design problems (unless you find a metric that can measure the semantical aspects of variable and class names, of course). Therefore a software metric can be used to find conspicuous code fragments that must be analyzed by hand to get substantial information. If Joel's consultant had read this book and had understood this concept we wouldn't need to be afraid of him any more.
The brilliant part of this book is the part about metrics visualization. If you ever ran cccc over a > 200kloc project, you know that visualization of metric results is hard. When I used cccc at work to assess our C++ project (before reading this book) I didn't find anything new or exciting in the results. The metrics showed me two or three structural problems that I was already aware of without using any metrics and quite a lot of false positives. After reading the book I came to the conclusion that it was not the metrics that were useless, but the simple brute force manner in which they were applied.
The idea of Lanza and Marinescu is to combine metrics in a way that answers specific questions about the code and visualize the results in a way that makes it easy for human beings to browse through the structure and especially to visualize the structure in combination with the metric results. If you want to learn more about how you can utilize metrics efficiently and how much work you have to invest to be able to use metrics at all, I highly recommend this book to you.
In the remainder of the book the authors try to give examples what metrics combinations should be used to detect specific structural problems and what refactoring should be used to solve a specific metric result. Those answers are often way to easy. If you're a fan of domain driven design, you are probably trying to base your design on the structure of the domain. So you can't just mechanically apply standard solution patterns to your problem, but you have to find the right kind of design for your problem domain.
For me this book was definitely worth reading. I'll try the tools mentioned in the book and see how the visualization techniques can be applied in real life. Since even the authors admit that metrics are most useful to get a starting point to assess legacy code, I don't think this book helps me a lot in my current work environment where I am still able to overlook the complete project. But the book helps you to view code and code metrics from a new angle, broadening your understanding.
nice read. Yes you are right. Nowadays everybody is afraid/hate to use metrics in the developing/maintenance phase as they think it does nothing useful to them. But in reality it does helps the team to produce better software.
what made me read your post was, im working on a product to measure software metrics and software visualization. try to take a look at that if you have time. available at http://swat4j.codeswat.com
[...] playing with fear? Yes, it is. Then again, no, it's not. It depends on what you do with the data. Metrics are a two-edged sword. You can use them to learn or to judge. Never do the [...]ReplyDelete
muddle filings ophthalmetrical subbreed apperception multihued anthophorous synonymicReplyDelete
The Wood Grain