6.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.) will fall short of the architect's expectations. Most likely, the disconnect between the architect's expectations and the work produced is not the result of malice or a lack of effort but rather is caused by a lack of understanding of what precisely the architect's standards are. In these early stages, detailed review is essential, and 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 undergoes a work review. Typically, the architect will receive arguments about the worth of producing deliverables that satisfy the standards, about whether the task description was clear enough to describe the desired deliverables sufficiently, 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 to insist that the additional work required to achieve the desired deliverable be performed in a timely manner. If this encounter is done well, the most avid detractors of the initial standards will eventually become their staunchest defenders, once the value of the standards 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. Unfortunately, the ability to assess the activities that are best delegated versus the activities that cannot be delegated without causing even greater problems can only come from overall experience and from working with a specific group. Another difficult task for software architects is finding the time to continually develop the necessary skill set so that the architects can be equally versatile after several years on the job.
However, a few pitfalls must be avoided. Software architects have the most visible technical role. Like it or not, they are also the technical role models for their teams and their actions have a direct impact on the actions and mentality of the team. Therefore, if they take or suggest shortcuts and kludges to resolve a development issue quickly, like it or not, they are implicitly advocating that others use similar means to resolve issues that they find problematic. Also, rest assured that less-experienced developers will encounter many more problems than will the architects, and the developers will be more than content to add numerous kludges to source code rather than ask for help in resolving the problems according to the known architectural principles. Similarly, if the code lacks a unit test or is not related back to the requirements specification, several developers will automatically follow the architect's lead. Therefore, software architects must conduct their efforts exactly as they expect others to conduct their own behavior. Starting off with a good example and maintaining it is far easier to accomplish than explaining why the developers are held to a different set of standards than the architects.
|
As silly as it may sound, an investment in a book on general etiquette and the time it takes to read and absorb it will always pay off handsomely. Most of the problems that will hurt the productivity of a development team are people problems rather than technical ones. Etiquette can frequently head off the people problems before they escalate into major obstacles. For the one or two individuals who are too foolish to heed this wisdom, here are a few of the most basic etiquette-related techniques that will help any software architect succeed:
Before criticizing the work of a team member, start the conversation off by identifying a few good things about the individual's work. Generalize criticism into a heuristic, using specific cases as examples of the heuristic not being followed, rather than immediately criticizing specific instances. Do not talk to people only when something is wrong. Let people know when their work and efforts are appreciated. Sometimes, just asking for feedback can be beneficial.
|
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. The decisions of the architect should be made based on his or her best technical knowledge. Not every decision is popular, but they are all based on an understanding of the various tradeoffs necessary to use various technologies and design approaches. Any question should either be answerable by recapping the known tradeoffs or be a source of information that 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 because 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 software architects do not constantly monitor 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 they are failing as software architects. Software architects cannot be effective without actively seeking out the real progress and direction of the project from the developers who are performing the actual work.
Software architects typically have knowledge and information that frequently exceeds that of many other team members. As a general rule, the architects 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 the software architect 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 understand the technical tradeoffs adequately -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.
Keep it simple.
When communicating various architectural concepts or software mechanisms to team members, resist the temptation to provide a complete and detailed explanation of how things work or a detailed comparison against all the alternatives in front of a group. Instead, the software architect should say enough to communicate the idea at a level that is high enough to be generalizable but just low enough to be understood in principle, so that the individual team members can do their own homework or meet separately with the architect to address their specific concerns. Let others defend the architecture.
It is always preferable to have someone else respond to a technical concern rather than have the software architect appear to be the sole source of knowledge. It reinforces teamwork, provides the architect with insights from people who agree as well as disagree, and is a key aspect in mentoring others, among other benefits. Act, don't argue.
Arguing technical points in a meeting wastes time, hurts feelings, and seldom if ever fully resolves any technical issues. When such an argument starts, the software architect must act-by assigning people to get or verify the relevant information, setting up a meeting specifically for resolving the debated topic, or, if time requires an immediate course of action, laying down the law by explaining why the time constraints force an end to the matter. Keep an eye on the prize.
Software architects must always be aware of the end goal. It is easy to be distracted by tasks and smaller technical issues, and frequently other team members will succumb to one form of tunnel vision or the other. However, it is vital that the architect always be focused on the overall vision of the system and relate every task or technology to how it contributes to the end goal. Be willing to change, but never too much at once.
After the initial bootstrapping of a software development effort, the architect should be wary of implementing too many process improvements all at once because there is a risk of compromising the effective parts of the process. Learn where to stop.
Software architects must resist the temptation to go into too many details and to micromanage design decisions. For example, it would typically be enough to specify that caching is required in client applications and that the caching code should be reused throughout the application. However, detailing the specific caching algorithm used or writing the caching pseudocode is probably overkill. Learning to trust other team members to provide design and implementation details and letting them ask for help is essential. Know how to follow.
No matter who is in charge, software architects should avoid publicly confronting others on major design issues. This can be accomplished by knowing ahead of time what is going to be discussed and the reasons for the various decisions. This is a key aspect to developing a focused, high-performance team.
|
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 to 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. Often, by asking the right questions of the developer, the developer will be able to reach an appropriate solution without needing direct guidance (e.g., the Socratic Method). In mediating technical disputes, the architect should articulate the issues and design tradeoffs that 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 believe that interacting with the architect is a learning experience. Furthermore, if at a later date the same technical issues are brought to the attention of the software architect, the architect should take the developer to task and ask why he or she didn't resolve such problems independently. 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, the architect should always make it clear that as soon as delays are anticipated, developers have an obligation to let the project manager know so that 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, the software architect needs to ensure that the bulk of his or 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.
 |
