I think the main point, in the development phase of a startup, is the uncertainness. I’m not talking here about the risk in terms of business (not my role..), but the uncertainness of what direction your project will take.

A lot of companies have changed their product in a radical way during the first phases of growth (like PayPal). Probably you will have to add new features or to cut others, but in every case you will rewrite a part of your software.

This is something that you cannot avoid. What you can do (and this is what I’m trying to do with Mashape’s code) is to simplify this future process.

Here we are trying to achieve this goal partitioning the main project in smaller projects.

For example the backend of Mashape (the java data structure, the persistence layer, the access to the file system, the runtime engine) has 51.000 LOC and is divided into 20 maven modules. This partition has, in my opinion, a great importance: when we will have the opportunity to hire someone, I will look for a developer better than me that will be able to refactor some of these projects without causing impact on the whole system (if the architecture of the project will result plausible).

Thanks to maven and its module system we are able to create a complex project structure that will be imported into Eclipse IDE with a simple command:

mvn eclipse:eclipse

Using a project management tool like Maven, you can handle easily a multi-module project, giving you the opportunity to divide the main project without adding too much “overload” to the complexity of the project itself.

Let me explain using an actual example: the DAO-DTO part is made up of 4 modules: the main project (defining all interfaces), the mock implementation (used during tests execution) and two modules that make up the hibernate impl.

The actual implementation is loaded using a configuration file, with two different files: one used in testing and the other for the deploy. But using this approach has another feature: in future we will be able to implement a new DAO-DTO with memcached and plug it into the system without impact on the rest of the code.

I’ve applied the same pattern to the file system access, with a basic module (that looks into the real file system) and a Hadoop version (still in development).

The last benefit that we received dividing our big project is that we always have a clear overview of project interactions and dependencies.. a vision that I often have not found in other projects and companies I’ve worked with in last years. And this clear vision is absolutely necessary to the project mantainability and future development