Modularity

For most of my programming career I believed in traditional modularity.  I no longer do.

Traditional modularity means hiding the implementation behind a clean interface.  This is usually done at the level of a class or group of classes.  One of the goals of this is to enable multiple programmers to work together on one project, the idea being that each programmer can own a few modules which can then work together in the application.  But in my experience, this just doesn't really work.  As code changes, interfaces change.  The programmers still need to coordinate and efficiency is much lower than when one programmer works on one small project.

I have managed up to about 30 programmers in one project, and I don't like doing this.  I much prefer working on small projects by myself.  I created the Luan programming language specifically for writing small applications.  The language is not designed to scale to big projects.  But now I have a Luan application that is growing, and I would like to hire programmers to help.  This forced me to reconsider the idea of modularity.

My application is a web store.  Since I know that small applications are the most efficient way to program, I want to split my big application into several small applications where each application is a component of the whole.  Examples of components are shipping, warehousing, and retail (user-facing).  Luan's hosting solution allows multiple Luan applications (websites) to be hosted in one process.  So applications can communicate intraprocess which is very efficient.

How does this differ from traditional modularity?  By being much more modular.  Each application/component has its own code base, its own database, and its own website.  They are truly independent.  Each programmer will get one application which he will completely own.  Inside applications, there is no need for modularity at all.  Application code should just be as simple as possible.