Before writing any code, we must decide the structure and setup of our application. How will our application break down into actual components or modules, and how do we manage these modules? What is the actual output of our application? Once we have a defined module to tackle, how should we start laying out our folder structure?

One of the biggest decisions starting out is whether to go with a monoloithic codebase, or to try and split our your application into more specific service oriented modules. While a monolith can be simpler starting out, it’s important to always keep in mind what components can be split into lean and re-usable modules.

The advantages of keeping your concerns focused to smaller use cases are many, and captured by the single responsibility principle. The basic idea is that we developers, as humans, have limited brainspace. Forcing us to balance more than even one responsibility has a significant cost – if we are looking to consider A & B, it’s likely we’ll do both less than optimally than if we were allowed to focus on A, and then B separately. For example, writing a general use validation library is going to be simpler than thinking about how to fit validation alongside all the other components of your application.

Often though, this principle can be extremely difficult to pull off correctly. That’s because it requires an almost preternatural sense for what the roles and responsibilites in a project will even be. Setting up the structure and organization of your project naturally needs to be one of the first steps, but that also means you have the least practical knowledge to apply.

This issue is actually not isolated to software at all. Instead, this is one of the many times where general engineering principles, or a basic sense of preparation and organization, will get you much farther than the stereotypical coding skills normally associated with software development excellence. Writing non-technical design documents for your project should naturally lead you to seeing these divides. These fit under the umbrella of “soft skills”

Apart from the simplification to developers of having one thing to model in their head at a time, we can have more tangible benefits as well depending on the framework and module system you’re working in. We’ll get more into these concrete benefits in, you guessed it, the concrete section.

Home | Next up