Notes on Alliances
At some point during the course, some teams will inevitably think about forming
alliances with other teams to help ensure that their module can be integrated
properly in the next phase of the course. Thinking ahead to the integration phase
is a good thing, and I don't want to discourage discussions about clearer interfaces
between modules. However, I do feel some specific guidelines are needed:
- If the alliances are formed purely to clarify the interface specifications
between the modules so that you can be reasonably sure the modules will work
together, that's fine. You can even use this as a marketing ploy ("buy our
module and we guarantee it will work with Team X's module"), although you
should be aware that this is a risk - no matter how good a job you do on the
interfaces, there may still be some integration issues, and your customers
might demand their money back!
The following are NOT allowed:
- Forming an alliance so that your teams can work to develop the phase 1 modules
together. This is collusion, and will be dealt with according to the University
guidelines for collusion between individuals.
- Forming an alliance to shut other teams out of trading. For example, if
you only sell to members of the alliance and refuse to sell to others (or
if you place restrictions in the contract that have the same effect), then
I will invoke the shut-out clause in the trading rules and force you to sell
your module at prices that you might not like.