You should develop a large system by building many small parts that are bound together (probably by scripts). The "big monolithic program" approach is insane:

You should develop a large system by building many small parts that are bound together (probably by scripts). The "big monolithic program" approach is insane: it invariably leads to reinventing wheels (e.g. there is no good reason for an office suite to have its own scripting language). Small parts can be written in whatever language makes sense for the task. Their partitioning leads to clean interfaces: command line options, file formats, or protocols, without which the parts could not be usefully combined. This has the great side effect of making each piece easier to test in isolation, as regression test data can be created for each part without regard for how the data reached that point. It also makes everything inherently more flexible, for unforeseen improvements. When you have small parts that are easily tested, you can easily replace them. This is the basis for innovation or other maintenance: if you really have to, you can confidently throw out one piece and put in something better that is compatible. It also helps immensely to open-source each part; at least, within your organization. It should not be surprising that people are more willing to contribute when there is something small they can wrap their heads around.