Building such an ambitious program with such a strong emphasis on software quality means building many subprograms, linking them together solely with well-designed interfaces, and creating an awful lot of documentation.
For the project to succeed, those programs, interfaces, and documents, plus the project as a whole, must have the following three properties:
It doesn't matter how hard we work on the program if it isn't extensible.
Outside programmers must be able to easily modify our code to suit their own needs or to accommodate new extensions they develop.
Consequently, our program must be very flexible. It should be possible to alter its structure at runtime without having to stop and recompile the program as a whole.
As far as possible, no class, module, package, agent or any other portion of the program should have any knowledge whatsoever of any other portion of the program. Everything, starting all the way down at the method level, should be as encapsulated as possible. Flexibility is a high priority.
It doesn't matter how flexible it is if isn't trustworthy.
Outside programmers must have faith in our code's ability to do what its documentation says it does without inexplicable failures so that they can add new features without worrying that the whole thing will collapse.
Consequently, our program must be robust and self-validating, and all its parts must be bug-free. Using assertions for critical methods, validating inputs, programming defensively, and so on, are all critical qualities in producing quality code. Robustness is a high priority.
It doesn't matter how robust it is if it isn't readable.
Outside programmers must be able to understand our code easily---and understand it in detail---if they are to extend it for their own purposes.
Consequently, our documentation must be extensive and exhaustive, starting from extensive in-line documentation, then class-level documentation, and on to package-level and project-level documentation, plus interaction diagrams for every level of code interaction.
A reasonably competent outside programmer should be able to spend at most a week reading the documentation and playing with the program to understand it all. It is better to provide too much documentation than too little, once it is well-written to begin with. Badly written documentation, no matter how extensive, will not communicate that the code was done by professionals and therefore will not inspire trust in the code. Clarity is a high priority.
In pursuit of these three goals we have to give other possible goals second place. First among them is efficiency (speed, memory use, storage use, code sharing, loop optimizing, and so on).
We all have a strong bias to produce the most efficient code possible and that is fine---code should always be as efficient as possible---but in pursuit of that we can't sacrifice flexibility (ability to reconfigure the architecture, even at the class level), robustness (strong resistance to bugs), and clarity (easily understood logical flow). Those three properties come first and foremost.
Once we have a flexible, stable, well-written program we can always worry about improving its efficiency later (or wait for faster machines with more memory! ).