is using diverse implementation technologies, such as different development environments or platforms (Java vs. .NET, C vs. COBOL, etc.), using construction techniques like Service-oriented Architecture or Component-based Development will come naturally. Focusing attention on the risky technologies or interfaces will cost little, and pay off nicely.
If the problem technologies are in a single development environment (as in the example earlier) then imposing one of the construction techniques may be more expensive, and must be integrated with the overall design of the project. Even late in project development, it may be possible to refactor some parts of the project towards a componentized structure. Software design patterns exist that can reduce coupling and increase the isolation of whatever technology is causing the problems. If this step is needed, you will have to have a good justification for requesting a change to the internals of the project. Defect metrics are your friend in this case. Also, regardless of how your suggestions on improving the code are received, do not be afraid to take action within the SCM domain to reflect what you know: impose extra process on defect-prone subsystems or technologies, and focus audits and reviews on the places you suspect problems exist.
Any technologically diverse project is likely to be complex enough that communications and information flow will be a problem. Organizational techniques like Change Control Board and System Architect will help. If the project is using diverse implementation technologies, finding a single architect can be a challenge-senior technical staff familiar with the whole gamut of technologies are comparatively few and far between. A CCB may be a safer bet in this case. But a CCB has its own problems, since the various board members will still have to explain to each other how and why something is causing a problem for them. CCB members in a multi-platform project should be sent to training on each of the technologies involved, if possible.
Coordination of work can be a problem in a technologically diverse project. Work Flow techniques that treat project components abstractly, such as Project Baseline and Longacre Deployment Management, can help address coordination problems. Project Baseline is a highly abstract technique, and will require architectural support from a construction technique (mentioned above). The size and timing of releases (baselines) in the Project Baseline approach is crucial for coordinating development among different components. Fortunately, the technique is adjustable, so problems with coordination can be "tuned" in a trial-and-error fashion. Longacre Deployment Management provides direct control over both the development and deployment of changes, so coordination of development is a more direct, hands-on activity. LDM makes rollback of deployments an expensive operation, though, so it pays to implement a certain amount of ceremony.
Ceremony plays a key part in managing technological diversity. When knowledge is not common, it must be made explicit. Ceremony does this. In many environments, testing and validation tools are available that can help technologies interoperate. Automated Enforcement of Standards can help teams "color inside the lines" by ensuring compliance with standards or executing test cases.
If compliance is difficult to determine in a scripted or automated manner, Gated Workflow can help by preventing work flow until manual steps have been performed. For example, in a project that needs human review of graphics, generated sound or speech, or timing. Alternatively, Gated Workflow may be the solution if compliance is checked at an aggregate level rather than on individual changes. For example, by running tests on a whole collection of changes, and associating the result with the package of changes. Telelogic Synergy uses this approach in their Task-based development model, approving or rejecting an entire bundle of changes as a single unit. When a test fails, though, individual work is required to decide which task(s) caused the test to fail.
The nature of compliance can be difficult to understand-a developer used to working in a GUI environment may not understand the request/response nature of web