A Question of Scale

This entry is part 2 of 8 in the series Design Principles

In the previous post we decided that there are a number of desirable properties that we’d like a software system to have. I’ll quickly repeat the ones I mentioned; A system should be Functional, Testable, Robust, Monitorable, Deployable, Scalable, Adaptable, Efficient and Elegant.

(There’s probably ample opportunity to create a catchy and memorable abbreviation out of these words, but let’s not.)

These properties can be achieved at different scales, or levels. By that I mean that they are affected by architectural (large scale) and design (medium scale) decisions as well as implementation (small scale) decisions.

So, in this series of articles, I am using the word "design" in a very broad sense, and not something limited to the designer role. These design principles is about reasoning how to create software, not just by hacking away on the problem at hand, but instead by having a plan at a higher level, describing how the system should be built to get a professional result by design (i.e. on purpose, not by accident). This plan should then affect everyone on the development team.

I could have called this series "friendly advice on how to increase the level of professionalism in your software development effort", but choose to use the word "design" to the same general meaning.

Role playing

First I’d like to elaborate a little on the differences and interconnections between the roles of architect, designer and implementer, as I will not place much focus on these individual roles later in this series.

I consider these roles to be more or less a matter of on which scale one operates on. The architect considers issues on the largest scale, how the whole will operate as a function of the major components, while the implementers (craftsmen) considers the issues on the smallest scale, performing the practical construction of the needed parts according to the designs.

The designer and architect roles are really only needed because sufficiently large systems have far too many "moving parts" for any one person to understand the entire system in any detail, and it becomes more efficient having some people focus on the general higher level goals, and delegate the lower level details on how to reach specific goals to others focusing on their part of the system.

How are these things connected?

The smaller the system, the less need for designer and architect skills on the team. If you are building a dog house, you don’t need to be an architect. However, as soon as the system complexity increases and it becomes composed of several cooperating services or applications, those skills become important. It’s hard to rescue bad architecture with good design, or a terrible design with good implementation. (On the other hand it’s simple to wreck even the best designs with a lousy implementation, anyone can do that!)

Analogies are often made between software construction and building construction. I guess that’s because building construction is easy to visualize, and that it shares roles and questions of scale with software construction.

The Sydney Opera House under constructionSo, let’s for a moment consider the Sydney Opera house. Surely an example of grand architecture! But is it also an example of grand design, and grand implementation?

I have no idea, but my point here is that at smaller scales, it could be a real mess! It does not follow that anything is superbly implemented at lower levels of detail, even though we can agree it is grand in the larger scales.

For example, the electrical wiring could be installed in an amateurish and unsafe manner, and placed where there are no easy access for maintenance workers.

The white ceramic tiles (manufactured in Sweden, by the way) could have been unprofessionally set on the roof in a way that let water in underneath, letting rust and mold starting to do damage to the building.

So the architect and designer(s) could have been doing a good job, but the craftsmen could have been amateurs, causing a whole lot of problems, that may last for the entire lifetime of the building.

And even if the architecture makes it a fantastic landmark, it could be that it is not optimally functional for an opera house. The Wikipedia entry indeed suggests that there are problems with the acoustics in the two major halls. But apparently the customer wanted both a landmark and an opera house, and then compromises was made.

This leads us to my next post in this series, where I’ll get to the first, and perhaps most important property of any system; being functional!

Series Navigation<< Principles of Software DesignA Functional System >>

Leave a Reply

Close Menu