Starting a new project is always exciting for a development team. Mirego being a service company, we happen to do a lot of that here.
Rather than starting from scratch every time, we approach each new project using the concept of boilerplates. We believe that it offers the most benefits in terms of reliability, productivity and maintainability with the least amount of compromise for the flexibility we need.
This article presents the philosophy behind this approach and what it allows us to accomplish.
The term “boilerplate” is used for a reference project that contains all our best practices in the development of digital products. In short, it’s a shell ready to accommodate the specific code of a new project.
When we start developing a new project, we duplicate these reference files and can immediately start implementing features specific to that project.
Through a set of open-source technologies found to be relevant in the majority of our projects, these good practices constitute a grouping of decisions and opinions that we maintain and that evolve over time.
1. Don't reinvent the wheel
There is nothing new with the concept of reusable code; developers have always leaned on it. Reusing the same lines of code in more than one situation greatly contributes to team productivity. The more this reusable code is at the base of a digital product (i.e., its foundations), the more its contribution to productivity is multiplied.
Over the years, we have come to realize that the majority of our projects had similar or identical foundations that became redundant to continuously rebuild.
By using a boilerplate, it becomes easy to develop projects that are more effective to maintain since they are based on the same foundations. Also, a developer who joins a new team will already be very familiar with the conventions of a project that would otherwise have been unknown to them.
2. Solid foundations and production-ready features
One element of boilerplates is the level of confidence we have in them. The entire code in these projects is currently deployed in production; there is no room for experimentation.
Moreover, before any functionality is integrated into a boilerplate, it must have at least been integrated and deployed in production on a project, not the opposite.
This ensures a very high level of reliability in the foundations of our new projects since we don’t integrate interesting features “for future projects”; we bring back production-ready features from mature projects.
3. Continuous improvement of our practices
Maintaining reference projects independently of ongoing projects makes it possible to treat them the same way we handle reusable libraries.
This means that they not only can but must evolve over time as our good practices evolve. Since we frequently start new projects, we often have the chance to revise our opinions and question these practices.
And as with any good reusable library, it’s important to expose the history of changes that are applied to give visibility on improvements, bug fixes, etc.
4. Open-source contribution to communities
We decided to publish these boilerplates under a public open-source license for two reasons: giving back to open-source communities and gaining the advantage of working with these communities.
The vast majority of the products we build are based on open-source technologies; it’s therefore quite normal that we want to give back to these communities by putting forward our best practices, our ways of doing things and our technological choices.
Making these projects publicly available also allows us to receive suggestions and improvements from the community to make these foundations even stronger.
By tailoring our approach with the use of boilerplates, we believe that we have found the right compromise between stable and solid foundations and flexibility as well as scalability.
These projects allow us to get started very quickly in the development of a new digital product without compromising stability, quality and maintainability.