I have always been a huge proponent for separation of concerns, code reusability, and code independence such that you can easily move code around, replace, re-use, etc. Even though often times you sacrifice speed due to additional layers of indirection, you gain much in maintainability. Maintainability is often an overlooked statistic as it is harder to measure than just time. However, as versions are released, use cases evolve, and technology stacks change, that maintenance nightmare can start to build quickly. Well balanced project structures can endure very well over time, far more than quickly thrown together projects. Even though a quick thrown together project can be shipped sooner, in the end it will fail to release version updates as fast and will result in a higher lifecycle cost (due to bugs, maintenance issues, etc). Anyways, enough with the project management side. What I really wanted to share was my ideal project structure that I am proposing to myself to use for future projects.
(more…)
