Category: Softwares

Creating an application requires many decisions to be made. Some might involve choosing a framework or library while others revolve around the use of specific design patterns. In either case the responsibility for the decision generally lies with the architect on the team. A stereotypical architect might gather all the information that can be gathered, then mull over it for a while, and finally decree the solution from the ivory tower for it to be implemented by the developers. Not surprisingly there is a better way.

In their work on lean development Mary and Tom Poppendieck describe a technique for making decisions. They argue that we should delay commitment until the last responsible moment, that is the moment at which, if the team does not make a decision, it is made for them; when inaction results in an outcome that is not (easily) reversible. This is prudent because the later a decision is made the more information is available on which to base the decision. However, in many cases more information is not the same as enough information, and we also know that the best decisions are made in hindsight. What does this mean for the good architect?

The architect should constantly be on the look out for decisions that will have to be made soon. Provided the team has more than a handful of developers and practices collective code ownership the architect can, when such a decision point approaches, ask several developers to come up with a solution to the problem and go with it for a while. As the last responsible moment arrives the team gets together and assesses the benefits and drawbacks of the different soutions. Usually, now with the benefit of hindsight, the best solution to the problem is apparent to everybody. The architect does not have to make the decision, he or she merely orchestrates the decision making process.

This approach works for small decisions as well as for large ones. It can allow a team to figure out whether or not to use the Hibernate templates provided by the Spring framework but it can equally answer the question of which JavaScript framework to use. The duration for which the different approaches evolve is obviously very dependent on the complexity of the decision.

Trying two or even more approaches to the same problem requires more effort than making a decision upfront and then just implementing one. However, chances are that an upfront decision leads to a solution that is later recognized to be sub-optimal, leaving the architect with a dilemma: either the team rolls back the current implementation or they live with the consequences, both of which result in wasted effort. Even worse, it is entirely possible that nobody on the team recognizes that the approach chosen is not the best one, because none of the alternatives were explored. In this case effort is wasted without any chance of addressing the waste. After all, trying multiple approaches might be the least expensive option.

As an architect we want to know how good the software is that we are developing. Its quality has an obvious external aspect, the software should be of value to its users, but there is also a more elusive internal aspect to quality, to do with the clarity of the design, the ease with which we can understand, maintain, and extend the software. When pressed for a definition, this is where we usually end up saying “I know it when I see it.” But how can we see quality?

In an architecture diagram little boxes represent entire systems and lines between them can mean anything: a dependency, the flow of data, or a shared resource such as a bus. These diagrams are a 30.000ft view, like a landscape seen from a plane. Typically the only other view available is the source code, which is comparable to a ground level view. Both views fail to convey much information about the quality of the software, one is too high level and the other provides so much information that we cannot see structure. Clearly, what is missing is a view in between, a 1000ft view.

This 1000ft view would provide information at the right level. It aggregates large amounts of data and multiple metrics, such as method count, class fan out, or cyclomatic complexity. The actual view very much depends on a specific aspect of quality. It can be a visual representation of a dependency graph, a bar chart that shows metrics at a class level, or a sophisticated polymetric view that correlates multiple input values.

Manually creating such views and keeping them in sync with the software is a hopeless endeavor. We need tools that create these views from the only true source, the source code. For some views, a design structure matrix for example, commercial tools exists but it is also surprisingly easy to create specialized views by combining small tools that extract data and metrics with generic visualization packages. A simple example would be to load the output from checkstyle, which is essentially a set of metrics on the class and method level, into a spreadsheet to render charts. The same metrics could also be shown as a tree-map using the InfoViz toolkit. A great tool to render complex dependency graphs is GraphViz.

Once a suitable view is available software quality becomes a little less subjective. It is possible to compare the software under development with a handful of similar systems. Comparing different revisions of the same system will give an indication of trends while comparing views of different subsystems can highlight outliers. Even with just a single diagram we can rely on our ability to spot patterns and perceive aesthetics. A well-balanced tree probably represents a successful class hierarchy, a harmonious set of boxes might show code that is organized into appropriately sized classes. Most of the time a very simple relationship holds: If it looks good it probably is good.