So the excitement of the days when I wrote stuff like Do You Understand XP? is gone. Rapid Development is a good book that reviews every practice it preaches with a critical eye, but I’m not overly excited. Yes, I learned, again, that many so-called Agile practices are known for a long time. But hey, I knew that after reading the Mythical Man Month. Excitement is hard to find in books these days. If I only could find one of those thought-provoking books, that rips your universe apart.

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.

Preceding events

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.

Reading…

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.

Conclusion

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.

This is what naturally happens when you grow software over a period of time. Since I didn’t have the mathematical background at the age of thirteen, short variable names seem to be a natural choice for human beings. You start with a seed and add functionality on a step-by-step basis, breaking up stuff at arbitrary boundaries.

I did appreciate the advantages of high level languages, though. When the 64k of BASIC data space and the interpreter’s performance limited my possibilities with regards to game programming, I started using C as primary language with some inline assembler for the critical parts. At that time I created my first library package for graphical functions and prototyped some game built upon this foundation.

This was my first technical domain abstraction. Splitting up the software in a library component and a domain component came naturally back than. Of course the library design was crappy and the programs were still tightly coupled to the library implementation.

At that time I also tried to learn C++ from the Borland C++ programming reference, but I couldn’t grasp the concepts. I probably didn’t really try to, thinking that I already knew how to create working software – I had a nice working repository of gimicks at that time.

The next critical step in my understanding of software design was to drop my arrogance.

One of my first software engineering classes at university covered the basics of object oriented software development in C++ using the STL. The first exercise we had to finish was a small program of which I don’t even remember what it was all about. A friend of mine and I worked on this exercise together. We both had programming experience and had a lot of fun hacking together a sharp-witted mess of code. The teaching assistant took his time to comment on every single part we messed up, giving us an overall rating of zero points.

This was the day I started to realize that the main challenge in programming is not to get a working program, but to create a maintainable, readable and easy to debug program.

At university I took part in a few programming projects and started an open source project with a fellow student. During those experiences I developed a strong sense of how structured abstraction can simplify software development. Then I started to work as a software developer and architect. When trying to communicate my architecture and design ideas, I realized that there are more aspects to software design than abstraction, low coupling and high cohesion. But, again, I couldn’t grasp the concepts.

“Domain-Driven Design” is all about this additional aspect to good software design – the domain language. You can build a piece of software with low coupling and high cohesion and superb technical abstractions in a technical language that restricts software evolution.

Eric Evans proposes a domain languages built upon phrases that describe the implementation of use cases in the software. This is a concept very similiar to test driven development, where you write down how you want to use your objects before implementing them, being able to change the design while writing the test.

But in “Domain-Driven Design” Evans demands a stronger concept: absorb the domain language from the domain experts. Build a coherent language to express concepts and design descisions.

The model couples the software to a pool of associations.

This is a new level of coupling encountered when building software. It is not related to the technical coupling of software modules. This is just what goes on in the brains of developers when confronted with software. The underlying model limits the way we think about software. This is not always bad, as a good model will bind the parts that are irrelevant during development and allows us to concentrate on the important aspects.

A domain driven model increases the probability that modules may be reused in the domain the software is developed for.

While many developers intuitively know what domain driven design is all about, Eric Evans manages to communicate the concepts in a way that makes them explicit, rather than implicitely hidden in the developers train of thought.

The book is not a page-turner, since most of the concepts are not new per se. It lacks the driven spirit of Kent Beck, or the deep insight of Fred Brook’s “Mythical Man Month”. I can’t say if “Domain-Driven Design” can help a student to boost design comprehension – I think it’s rather hard to read if you lack the medium level knowledge the concepts in this book are built upon. But I recommend this book to those that already know what software design is all about intuitively and want to be able to put a finger upon the “big picture”.

During my studies of computer science I mostly read scientistic articles and scripts written by scientists for scientists. This information was invaluable for laying a foundation of technical knowledge. While studiying I learned mostly by trying out new interesting things, coding open source software and endless discussions with fellow students.

When I started to work I felt confident in my field. I expected to learn a lot on a learning-by-doing basis, or by listening closely to the veteran software developers around me. After two years of architecturing and coding in the real world, my enthusiasm mixed with an exhausted feeling that you just can’t tackle the complexity of software development effectively.

When I visited New York City at christmas ‘05 I spent a lot of my time rummaging through bookstores full of English books (which are rather spare here in Germany). There I stumled across a copy of “The Pragmatic Programmer”. Since I had read about the title allready somewhere on the internet and didn’t have anything to read at that time, I bought me the copy.

I read this book on my flight from New York to Munich in one go. Andrew Hunt and David Thomas managed to light that spark of hope inside of me that there may be a silver bullet after all. They draw an abstract view on software development, they help us step back to take a look at ourselves and how we’re doing things. They explain the world around the software developer and show why it is important to explain the process and not only the tools used to produce code. They inspired me to read “Extreme Programming Explained” by Kent Beck, to join IEEE and utilize their library to learn from the experience of fellow software developers. As with my first computer book, “The Pragmatic Programmer” is by no means as insightful as “The Mythical Man Month” or as complete as “Code Complete”, but it is inspiring in it’s mission to make programmers deliver better software to the world.

I’d definitely recommend this book to any programmer who hasn’t read a book about software development for some time and is just not satisfied with the way software is created nowadays.