5.3. Always Insist on Excellence in Deliverables

A responsibility of the software architect is to review developers' work products. Inevitably, in the early stages of a new effort, it is likely that several of the work products (use cases, designs, test plans, etc.) are going to fall short of the architect's expectations. Most likely, the disconnect between the architect's expectations and the work produced is due not to malice or a lack of effort but rather to a lack of understanding of what precisely the architect's standards are. It is in these early stages where detailed review is essential and where the architect must insist on excellence in the work products produced. This should be done professionally and politely, however; the quality and level of effort must not be compromised. If the architect does not insist upon excellence in the early development process, it is unlikely that it will ever be achieved in future iterations.

An architect should expect some resistance the first time any experienced developer has to undergo a work review. Typically, the architect will receive arguments about the worth of producing deliverables which satisfy the standards, about whether the task description was clear enough to sufficiently describe the desired deliverables, and a thousand or so similar variants, most of which blame the standards and the architect rather than the developer. The software architect's best course of action is to be gracious and accept full blame and responsibility, but insist that the additional work required to achieve the desired deliverable is performed in a timely manner. If this is done well, the most avid detractors of the initial standards will eventually become their staunchest defenders, once their value has been demonstrated later in the development process. When integration time is reduced by two thirds by having clear and very specific design documents, no one on the team will want to proceed to implementation and integration without them ever again.

The software architect must be versatile and set an example for the rest of the development team to follow. For example, if the project is at risk of being delayed because a critical design is missing, frequently the best contribution the architect can make is either to sit down with the group and jointly develop the design, or sometimes, particularly if the subsystem slipped through the cracks at task assignment, to produce the design independently. In either case, the architect should adhere to the same process, in terms of documentation guidelines and reviews, that everyone else on the team adheres to. Similarly, if integration is delayed because of problems in debugging tricky parts of the source code, ideally the architect will sit with the developers and, if all goes well, assist in rapidly resolving the obstacles. Not surprisingly, this aspect of being a software architect frequently comes easily to new architects, as it was a responsibility also assumed by them as experienced developers. The more difficult part is finding the time to continually develop the architect's skill set so he can be equally versatile after several years as a software architect.

However, there are a few pitfalls which must be avoided. As the software architect, you have the most visible technical role. Like it or not, you are also the technical role model for the team and your actions directly impact their actions and mentality. Therefore, if you take or suggest shortcuts and kludges to quickly resolve a development issue, like it or not, you are implicitly advocating that others use similar means to resolve issues which they find problematic. Also, rest assured that less experienced developers will encounter many more things which are problematic than will the architect, and they will be more than content with adding numerous kludges to source code rather than asking for help in resolving the problems according to the known architectural principles. Similarly, if your code lacks a unit test or is not related back to the requirements specification, you will immediately discover several developers who automatically are following your lead. Therefore, as the architect, you must conduct your efforts exactly as you expect others to conduct their own behavior. It is far easier to start off with a good example and maintain it, than it is to explain why you didn't and yet still expect others to conform to your stated standards.

Just as serving as an example to the development team comes easily to most new software architects, having confidence and courage when first appointed as the architect typically does not. At a minimum, a software architect's courage should take two forms. First, no technical question should ever be feared by the architect. The decisions of the architect should be made based on his best technical knowledge. Not every decision is popular, but they are all based on understanding the various tradeoffs in making use of various technologies and design approaches. Any question should either be answerable by recapping the known tradeoffs or be a source of information which may require that an existing tradeoff be reevaluated. Neither case reflects badly upon the architect, since honestly considering questions and hearing new information, even from critics, is a perfectly valid technique of information acquisition! A software architect should welcome both types of questions without getting agitated, as they both provide practice in articulating the project's architectural vision and may lead to cases where the vision is further refined in light of new information. Second, the architect should never be afraid of making a concrete decision.

One constant in software development is that good software architecture never just happens. It must be planned, monitored and defended over the lifetime of the software. If, as a software architect, you are not constantly monitoring the execution of software processes to verify that the architectural principles and guidelines established at the outset of the project are adhered to and maintained, then you are failing in your role. A software architect cannot be effective without actively seeking out the real progress and direction of the project from the developers who are performing the actual work.

As a software architect, you have knowledge and information which frequently exceed that of many team members. As a general rule, the architect should be willing to share information with other team members and trust them to use it constructively. For example, if the team is incorporating a technology with known limitations, such as the CORBA marshalling delays with complex data types, then it should be willing to acknowledge the problem and discuss why the benefits of the technology are sufficient to overcome its limitations. While information sharing may occasionally be damaging—for example, by bringing up the limitations to higher-level management who may be unable to adequately understand the technical tradeoffs—in the long run it builds trust among team members and enables them to develop solutions rather than waste time rediscovering known problems. An environment where the cumulative knowledge of the entire team can be brought to bear, both in solving problems and in seeking out still more knowledge, is the most ideal for software development. Little is more disappointing than seeing a talented architect attempt to horde information, which typically becomes obsolete at a faster rate than it can be stockpiled.

The software architect serves as a technical mentor to other developers on a project. Often the architect is asked to help resolve technical problems or mediate a technical dispute between two parties. Rather than simply resolving the technical problem or deciding between the two alternatives, the software architect should go the extra mile. In the case of technical problem solving, the architect should walk the developer through the steps necessary to resolve the problem at a level of detail low enough that the developer can resolve similar problems in the future without additional aid. In mediating technical disputes, the architect should articulate the issues and design tradeoffs which make a particular alternative more desirable in a particular case than the competing alternative. If possible, the architect should figure out the concerns being addressed by the inferior alternative, and point out what elements are missing in the current case which, if present, would make that alternative more desirable. Ultimately, team members should feel that interacting with the architect is a learning experience. Furthermore, if the same technical issues are brought to the attention of the software architect, take the developer to task and ask why he/she doesn't feel comfortable resolving such problems without your assistance. Eliminating road blocks to applying new knowledge is an easy way to improve the efficiency of a development team.

A software architect should always be willing to hold team members accountable for their lack of productivity. If a design is overdue, it is reasonable to ask for the reason for the delay and a description of where the elapsed time has been spent. Similarly, if a coding task is delayed, getting specific details about whether the delay was caused by problems in the design, debugging a tricky section of code, or unforeseen complexity in the implementation is vital. Such information can lead the architect to gain productivity increases across the board by conducting debugging tutorials or by improving design review procedures. Also, always make it clear that as soon as delays are anticipated, developers have an obligation to let the project manager know so tasks can be replanned accordingly.

Most development efforts, even ones with mature processes and an experienced team, cannot avoid some degree of chaos. Left unchecked, the unexpected technical and organizational issues could occupy just about all of the software architect's time. However, any software architect needs to ensure that the bulk of his/her time is devoted to issues internal to the development team. An effective architect must always be available on relatively short notice to attend to the team's internal details, which may delay development if not attended to promptly. These issues include resolving disputes over interfaces between various subsystems, weighing in on problems caused by product upgrades, or providing verification that certain design approaches aren't in violation of the architect's vision of the system.