What Color Are My Shoes?

My blog posts related to IT strategy, enterprise architecture, digital transformation, and cloud have moved to a new home: ArchitectElevator.com.

Martin Fowler once said that you can tell a social geek by the fact that he looks at the other person’s shoes. While this makes for a good joke I have actually found that there is a distinct group of software developers who are quite social and well connected. When someone asked me recently how I keep up on all the happenings in the software world I realized that I do a good portion of it by hanging out around the people who know a lot more than I do. This can mean a pub crawl in London, late nights at the TechEd speaker hotel, or the Tangosol party at JavaOne.

Over time I have actually become used to attending conferences not so much for the session content but for the networking and hallway or bar discussions. Apparently I am not alone because Bruce Eckel created a “conference” just for people like me. This “conference” includes only people who are usually speakers at other conferences (or easily could be) and it features a very loosely structured format that is reminiscent of a dinner or beer discussion. Because of the selective audience the noise level at the event is very low and marketing is completely absent because we have nothing to sell to each other. For the past 3 years I have always left a little smarter and quite inspired. Since the audience for such an event is naturally limited this year I want to share some of the topics we discussed. Each of the topics is probably worth its own blog entry so I will expand the ones I find particularly interesting. But here a few sound bytes to wet your appetite. Note that these notes were derived from discussion groups rather than prepared talks so that the "conclusions" take a smaller role than the exchange of experiences and opinions.

Attributes / Annotations

Metadata in the code (aka Attributes / Annotations) is the shiny new toy in both the C# and Java world. Having worked with C# for a while I can’t help myself but to be amused and irritated by the fact that Sun used to tell Java developers that all this “syntactic sugar” is superfluous, just to completely change their mind once the competition moved in. So either they were lying all along or they have no spine. But anyway, before I start to sound like Hani, let me share some of our discussions around metadata annotations.

One of the problems with every new tool is that it is hard to determine what the boundaries of its best usage are unless you actually cross those boundaries. I think many people went through that experience with attributes not too long ago. In order to shorten the learning cycle we exchanged some experiences and opinions on proper use of attributes.

• Attributes (I’ll avoid the "attributes / annotations" going forward – I don’t get paid by the word…) are usually a good replacement for naming conventions. For example, nUnit replaced the old testXYZ naming convention with a [TestCase] attribute. However, be careful to consider subtle differences. For example, if you use SetUp as the naming convention for a setup method, only one method in each class can have this name (assuming an empty list of parameters). If you use an attribute, you need to decide whether you want to allow multiple methods to be marked this way and, if so, what the desired behavior is. Moreover, if you allow inheritance do you want to automatically “inherit” the attribute to the child class? You might end up building some of the compiler infrastructure yourself in order to get the behavior. So be careful if the behavior associated with the attribute is more complex than “for every method with the attribute do X”.
• Another common usage of attributes is to replace a marker interface, i.e. an interface that does not contain any methods. These interfaces are often used to categorize classes or specify inherent properties (e.g. is the class reentrant, serializable etc). This seems to be the sweet spot for attributes because it keeps us from abusing a language construct such as interfaces. However, we have to keep in mind that with attributes we cannot declare a method that takes only a ISerializable. Instead, we would have to perform the equivalent check explicitly and at run-time, reducing the amount of validation the compiler can do for us.
• The general sentiment was that using attributes to specify external configuration is a slippery slope. For example, I have been often frustrated by the attribute-happy .asmx Web service configuration. What if I want to change the SoapAction name at deployment time? Attributes are part of the source code after all and require access to the source code. Microsoft Indigo is fixing this aspect by allowing all configuration to be specified either as attributes, as code, or in a config file. Another example of external configuration is provided by the EJB 3.0 configuration of schema and table name of an entity: @Entity @Table(name=”…” schema=”…”) . This is information that is typically intended to be changed at deployment time and it will be cumbersome (at the least) to have to edit source code and rebuild the application. On the other hand though, for very simple apps this usage can be more explicit (and hence more readable) than an external configuration file. So as in most cases, the world is not exactly black and white.
• A less obvious but very effective use of attributes is to assist external tools in the creation of documentation or diagrams. This can go far beyond the usual JavaDoc approach of using comment blocks with specific notations. For example, I could come up with a set of attributes to designate “critical classes” that should be shown in a high-level dependency diagram. Classes that do not carry this attribute might only be included in a more detailed diagram. Or I could assign colors to my classes so the software can create color coded diagrams. In either scenario, the attribute is used by an external program, but it denotes a property of the class itself, e.g. whether the class is “important”.

In summary people appreciated attributes because they can make properties of a class (or the application of a cross-cutting concern) a lot more visible in the class source. However, caution should be exercised that the attributed truly denotes a property of the class itself and not a property or relationship external to the class (e.g. the table or Web service configuration described above).

Model Extraction / Visualization

I have previously declared my love for visualizations. I am quite convinced that many people do not have enough of a “big picture” of what their system looks like. Visualizations are very powerful tools, especially considering humans’ ability to quickly recognize patterns in complex diagrams. The gist of model extraction is to use modeling not to generate source code but to use source code (or a running system) to extract a model. Essentially you define a metamodel (yeah, big word, I know) and then apply the actual system against this metamodel. For example, a directed graph is a very popular metamodel and can be used very well to depict dependencies, message flows and the like. Once you have this model you can use it for validations, visualizations etc.

One of the shortcomings of most visualizations is that they tend not to scale very well, exemplified by the proverbial 3’ by 4’ database schema poster that is entirely useless. I think that assisted model generation using attributes can help in this category. You can actively decorate your source code with metadata to distinguish “important” from “unimportant” elements etc. This type of decoration (using attributes in the source) are particularly useful because they convey intent (i.e. the “why”) as opposed to the “how”. The latter is (well, should be) quite obvious in the source code itself and does not require any further explanation (reminding me of my favorite source comment // sets variable x to zero).

Another way to convey relevant information without running our of paper is to use polymetric diagrams, i.e., diagrams that convey more than one metric in a single picture. The most famous example of a polymetric chart is likely the map of napoleon’s Russia campaign. Erik showed us Code Crawler which provides a host of visualizations that use position, size, shading and shape to convey multiple aspects of your source code. Unfortunately, is runs only on SmallTalk but an Eclipse plug-in allows for conversion from Java code. Erik showed some very cool visualizations that show class lines of code, the number of methods and the number of fields in a single diagram.

Mixing Architectural Styles

I hosted the topic of mixing multiple architectural styles in a single application. This topic is close to my heart since I spend a lot of time with workflow engines, messaging, rules engines, document transformations and other non-OO stuff. Each of these tools and engines is based on a different architectural style and often uses a different programming languages (e.g., BPEL, XSLT, etc). Some of the topics we discussed included when an application layer becomes complex enough to warrant a new style and whether this style should be based on the core language (e.g. Java or X#) or whether a whole new language should be created. When creating a new language, you have further choices, such as whether to use a "standard" language or create your own domain language. As this post is already getting lengthy (and slow in coming along) I’ll postpone a more detailed discussion to a separate post. Plus, this topic makes a great segue to the next item.

Domain Specific Languages (DSL's)

Many of us believe that DSLs are the “next big thing” on the horizon for enterprise software development. Some very early tools are starting to appear, such as JetBrains' MPS or Microsoft's Visual Studio 2005 DSL Tools. Other tools, like the Intentional Programming work continue to be shrouded in mystery.

Goal-based Design

Einar hosted a great session on goal-based design used primarily in the context of agent systems. Agent-based systems consists of a collection of collaborating agents, which in unison accomplish an overall goal. The individual agents' behavior is based on their belief (aka state), their goal (a completeness condition) and their plan (an algorithm of sorts). Agent-based systems can be very effective at breaking down complex goals into small, manageable tasks. Agent-based systems are generally associated more with the academic fringe, with many commercial tools being quite expensive and mostly limited to military applications. However, some open source alternatives seem to be appearing.

To me two discussion items stood out particularly:

• Agent-based design tends to focus on the interaction between components over (or in addition to) the internal structure of them. Modeling the interaction between agents is quite analogous to the interaction between loosely coupled services, which is one of my current areas of interest. During this discussion I learned that the much cursed UML 2.0 spec added semantics to the sequence diagram so that it can now express interaction rules as opposed to just a single instance of many possible possible interactions. The notation might take some getting used to but then Petri Nets are not everybody's favorite either.
• I like the idea that goal-based design represents overall goals in the system design. Einar's book showed an example of a book store with the overall goal of "ensure books are in stock". I feel that these kind of goals are too often stated somewhere in a project charter but too rarely make it into actual designs. In this example, the overall goal broke down into the sub-goals "reorder books", "track outgoing books" and "track incoming books". I have to admit I have not thought this 100% through but the approach seems appealing.

I guess I have to buy the bullet and get the (pricey) book that Einar was reading. The book does not as much talk about what agents are but focuses instead on a methodology to design agent-based systems.