Beautiful Structure

In response to O’Reilly’s just-published Beautiful Code, Johnathan Edwards explains why he couldn’t go along with the premise. One sentence in his excellent piece stood out for me:

“The human mind can not grasp the complexity of a moderately sized program, much less the monster systems we build today.”

This is true, but only to a point. Clearly it is humanly impossible to understand the whole “design” of a million-line code-base by studying just the lines of code. But hopefully that is not necessary.

If it’s written in an OO language, then I’m mentally constructing class diagrams as I read the code. Much better if these are visible to me – I can work on understanding the class-level structures, dipping down to the code-level as I need to.

I’m still not going to make sense of thousands of classes as a single conceptual group, But that’s not what I’m going to do. I’ll start organizing the classes into groups. Ideally this was done as the code-base evolved and I have some physical representation of these groups to help me with my task. In Java, the package structure largely serves this purpose. Understanding the package hierarchy and interdependecies (in conjuction with dipping down to the class and code-levels) is not going to be a cake walk, but if the hierarchies are well-structured, it is surely possible.

The degree to which my million line code-base can be understood is therefore largely dependent on:

1. How well the hierarchies are structured
2. How good a job they do in explaining the code-base

1 is pretty easy to measure (a lack of cyclic dependencies; not too much complexity at any point of breakout in the hierarchy). But being measurable, I’d call this “quality” rather than “beauty”.

2 depends on 1, but goes a step further. It requires the inspired human touch. Herein lies the beauty.

The bottom line is that structure and architecture are an intrinsic part of the code, and any discussion of code “beauty” without them isn’t going to work for today’s monster systems.