Wilfred Thinking Aloud

Growing a Log

Tonight, I added a couple of more capabilities to the Blammo logging framework. Some of it has been done in order to provide some suppport for Sun's Unified Logging Format. The Unified Logging Format dictates that the message id is prefixing the actual message. Blammo already allowed you to specify the message id explicitly, but I wanted to have Blammo generate it for me, so I added that capability. Additionally, I added a mechanism to copy the JavaDoc comments for a certain event to the message catalog as an explanation.

That means that a message catalog could now potentially look like this:

The message ids have been generated, using the BLAM prefix and starting from message number 200. Both these properties are specified in the relevant section in your Maven pom:

      <plugin>
        <groupId>com.agilejava.blammo</groupId>
        <artifactId>blammo-maven-plugin</artifactId>
        <version>0.1-SNAPSHOT</version>
        <configuration>
          <messageIdPrefix>BLAM</messageIdPrefix>
          <messageIdOffset>200</messageIdOffset>
        </configuration>
      </plugin>

The additional comments for a certain message have been copied from the interface definition of the logger:

    /**
     * @blammo.logger
     */
    public interface EventLogger {

        /**
         * The application has attempted to divide something by zero, which is
         * impossible. This is a bug.
         * 
         * @blammo.level warn
         * @blammo.message Attempt to divide {a} by {b}; returning 0 instead.
         */
        void logDivisionByZero(int a, int b);

Agile vs. Monumental

A couple of days ago, I again experienced that traffic jams are just excellent opportunities for contemplation. While thinking about some recent experiences doing architecture work, my mind drifted off and I found myself trying comparing the different definitions of architecture of my customers. (I also found myself in need of the emergency break.)

All of a sudden, it dawned into me that these customers not only had different ideas on the approach for producing the architecture, but also different objectives. I'm sure everybody already figured that out, but quite honest, it was a nano-revelation for me.

I always figured that the objectives of the agile architect were similar to the objectives of the monumental architect, e.g. guarding systemic qualities like performance, scalability, security, etc. But I think I've come to believe that these are really 'afterthoughts' for the agile architect: we will fix it if it becomes a problem.

There is however one thing that can never be an afterthought in an agile project. The focus of an agile architect (aka coach) is predominantly on guarding a quality that is generally not listed as a systemic quality. The agile architect focuses on parallelization of the development process.

If working in parallel is not a requirement, then providing structuring principles is not necessary at all. However, if the size of the team increases beyond two, then there is a need to provide more structure, since people will need to work in parallel.