It is tough to have the architecture right, and it is tougher to measure its complexity. Grady Booch explains why metrics fail.
Assuming that one can even calculate the complexity of a system’s architecture, what value should you expect in that number? Simply knowing that system A has complexity X versus system B (or a different implementation of A) has complexity Y may be a fascinating curiosity, but then what? Does one try to do something (refactor the architecture) to optimize the value of the metric? Possibly, but the danger, of course, is that one may end up optimizing that number but at no material value to the use or economics of the system, or even worse, at the cost destroying some other important aspect of the system.
Of course, comparing architectures of two different software systems cannot yield much value, and trying to measure their complexities will give only false results. The complexity of an architecture is not technical, it is about the system, its subsystems and their interaction. An architecture has to be considered in a context to think about the complexity. That will bring out the necessary elements, that act as soul of the system, in the architecture. Only numbers do not do justice to highligh either the pros or cons of the selected architecture. Like in simplicity, perception is going to factor into complexity. That is one of the reasons, like Booch has mentioned
I can “feel” that one system or implementation is more or less complex than another, but I can’t empirically defend that feeling in many cases.
I for one think that metrics, wherever they are used, can only be indications. They themselves cannot represent the topic under consideration. I think it makes a lot of difference when we try to define the environment along with the metrics. For example, answers to complex for whom, when and how can provide lot of information. There cannot be any empirical measures or explanations for complexity.
February 16th, 2007 at 9:51 am
Hmm, interesting, but I think you may be too dismissive of these metrics. It’s true, it’s very hard to come up with a metric for a design. By definition design is an ill defined problem, but we do have subjects like aesthetics which nonetheless try (and often succeed) in providing fairly strong indicators of what makes a ‘good design’.
In the world of software, I would argue that any system that implements the same functionality with less code is bound to be better. It’s Occam’s Razor, nothing new. And I don’t mean this in an ‘obfuscated’ code way, where you squeeze every whitespace character to reduce ‘complexity’. Rather, a good architecture accomplishes a well defined goal in a concise manner. 37Signals is a good example, they do an excellent job on their products, and they have great architecture – their problems are well defined and well executed.
February 16th, 2007 at 3:36 pm
Ilya, I agree with you that metrics are useful in some cases. However, only the metrics by themselves might not give the whole picture. For example, less code can be better. However, does less code mean simple code? What if comprehensible code is what is more warranted. Also, a lot of times the architecture is bound by other factors like necessity to use existing resources. I think measures should include these factors along with the metrics.
February 17th, 2007 at 11:00 am
Abhijit, that’s true, but I think you could also argue that for a non-trivial system your choice of tools/languages is going to be domain specific anyway. So if you’re building an ‘expert’ system which needs to search and infer from a large database of rules/facts, a prolog (like) language is an obvious choice.
In part, your application defines your tools. But even then, I think the value of a ‘tool’ is often overrated. You often come across an irate ‘x’ language supporter – “x is the best language, etc.” The problem with this approach is that these people often confuse the tool with the ends. A language is supposed to facilitate your problem solving, not do it for you.