Admittedly, I’ve been struggling with the “Architect” title in the IT world. It is not that I think there’s no role for architecture, far from it, but too often I’ve encountered architects who focus too narrowly on architecture, losing track of the realities of actual software development and the context in which the software will be used. I wonder, if there was no “Architect” title and people who are responsible for architecture would be called guide or coach or tech lead, or just the senior developer, whether things would be better.

About a year ago, in a discussion about architects, rather than trying to define what an architect is or does, we looked at what he or she should know. We expressed our ideas as mini-essays, strictly limiting ourselves to one per essay, and it turned out that, at least to my surprise, there was a lot of agreement; maybe because we hadn’t come up with hard and fast rules but with ideas and guidelines.

Luckily Richard Monson-Haefel was part of that discussion and he had the resolve and means to make our thoughts more widely available. Our list of the 97 things every architect should know was collected and refined on this wiki, and is available under a creative commons license. For a more convenient read it has now also been published as a book by O’Reilly. As expected, the discussions have begun.

The JAOO conference is coming to Australia again, and I think it will be the best technical conference in Australia this year. (I admit that I’m somewhat biased as a member of the programme committee.) In the lead up to the conference we have organised what we call JAOO Nights in Brisbane, Melbourne, and Sydney. These are free events, starting at 5pm with two speakers presenting on topics that give a flavour of what the JAOO conference itself will be like.

Check out the JAOO Australia site for information on the sessions, and sign up for your city if your interested!

If you are somebody who writes code you probably know that moment when you look at some code you didn’t write, or some code you wrote a long time ago, and you think “that doesn’t look good.” Ok, more realistically, you probably think “WTF? I wouldn’t want to touch that with a barge-pole!” It is not even so much about whether the code does what it should do—that takes a bit longer to figure out—or whether the code is too slow. Even if it’s perfectly bug free and performs well, there’s something to the way it’s written. This is part of the internal quality of a software system, something that the users and development managers can’t observe directly; yet, it still affects them because code with poor internal quality is hard to maintain and extend.

Now, as a developer, how do you help managers and business people understand the internal quality of code? They generally want a bit more than “it’s horrible” before they prioritise cleaning up the code over implementing new features that directly deliver business value. Or even: how do you figure out for yourself how bad some code actually is in relation to some other code? These were questions that Chris Brown, Darren Hobbs, and myself were asking ourselves a couple of years ago.

The answer came in the form of a simple bar chart, arguably not the most sophisticated visualisation but a very effective one. And our colleague Ross Pettit had the perfect name for it: The Toxicity Chart. Read on to see what it is and how it’s created.

Read the rest of this entry »

One of my favourite tools to render graphs is GraphViz Dot and in an earlier entry I described how to use it to visualise Spring contexts. Today I want to showcase a different application.

Call graphs show how methods call each other, which can be useful for a variety of reasons. The example I use here is the graph rooted in a unit test suite, and in this case the graph gives an understanding of how localised the unit tests are, how much they are real unit tests or how close they are to mini-integration tests. In an ideal case the test method should call the method under test and nothing else. However, even with mock objects that’s not always practical. And if, like myself, you fall into the classicist camp of unit testers, as described by Martin Fowler in Mocks aren’t Stubs, you might actually not be too fussed about a few objects being involved in a single test. In either case, looking at the call graph shows you exactly which methods are covered by which unit tests.

There are several ways to generate calls graphs and I’m opting for dynamic analysis, which simply records the call graph while the code is being executed. A good theoretical reason is that dynamic analysis can handle polymorphism but a more practical reason is that it’s actually really easy to do dynamic analysis; provided you use the right tools. The approach I describe in this article uses Eclipse AJDT to run the unit tests with a simple Java aspect that records the call graph and writes it out into a format that can be rendered more or less directly with Dot. Of course, this technique is not limited to creating graphs for unit test; it only depends on weaving an AspectJ aspect into a Java application.

Read the rest of this entry »

The Spring framework has become ubiquitous in the Java world, and there are a large number of tools supporting developers of Spring-based applications. In this post I describe SpringViz; or, more accurately, my variant of it.

SpringViz helps developers with what is at the heart of a Spring-based application, the container and the contexts files that describe the beans. In larger projects these context files can grow quite a bit. Newer versions of the Spring framework introduced features that help reduce the clutter and there are vast numbers of blog posts voicing different opinions on what should and what shouldn’t be in a context file but, no matter what, the number of beans in the context files will grow with the size of a project, and at some point it becomes difficult to understand the overall structure. This is no different from trying to maintain an understanding of a large codebase. In fact, I consider the context files to be code rather than configuration.

I’ve argued before (here and here for example) that to deal with the complexity and sheer size of software systems we need a 1000ft view. This is a view that uses visualisation techniques to aggregate large amounts of data and multiple metrics into one big picture. SpringViz provides that 1000ft view for Spring context files.

Read the rest of this entry »