So it is today. Schedule disaster，fiinctional misfits，and system bugs all arise because the left hand doesn't know what the right hand is doing. As work （/） ，the several teams slowly change the functions，sizes，and speeds of their own programs，and they explicitly or implicitly （/） their assumptions about the inputs available and the uses to be made of the outputs.
For example，the implementer of a program-overlaying function may run into problems and reduce speed relying on statistics that show how （ ） this fiinction will arise in application programs. Meanwhile，back at the ranch，his neighbor may be designing a major part of the supervisor so that it critically depends upon the speed of this function. This change in speed itself becomes a major specification change，and it needs to be proclaimed abroad and weighed from a system point of view.
How，then，shall teams （/） with one another? In as many ways as possible.
• Informally. Good telephone service and a clear definition of intergroup dependencies will encourage the hundreds of calls upon which common interpretation of written documents depends.
• Meetings. Regular project meetings，with one team after another giving technical briefings，are （/） . Hundreds of minor misunderstandings get smoked out this way.
• Workbook. A formal project workbook must be started at the beginning.