In Boilerplates We Trust
How boilerplates add value and why we choose them
Every software development studio should be readily equipped with a tailored boilerplate for each of the technologies they provide services for.
This is a bold statement, but one which we live by.
Imagine this: your team is kicking off a brand-new project. You have to estimate requirements, weigh in resources, and so on. Are you including here the time it takes to simply start from scratch? The setup, configuration, scaffolding and implementation of the most basic features? What if you needn’t include this? Can you visualize all the emerging advantages?
A boilerplate basically refers to any code that needs to be reused in many contexts without significant changes. This goes hand in hand with the related term “bookkeeping code”: basic code that does not make up the product’s differential value. Building this is still an essential part of the developer’s work, but it goes unnoticed to the end-user (much like Housekeeping genes, if you may).
Originally, boilerplates were needed in cases where the number of actual product-specific features was low, and the cost/benefit ratio of implementation from scratch was too high. But this concept has branched off in time, and lately we find ourselves making use of these tools even for complex applications where there’s still a common overlap in code patterns.
Having a continuously up-to-date boilerplate, precisely scoped to handle the commonest scenarios, is highly beneficial to developers and product owners both. Let’s examine why.
1 — Decreased development times
Easily the main advantage for all parties involved. As mentioned, using a boilerplate as part of your toolkit to kick off a project will undoubtedly boost the team’s speed at completing features that give the most value to a product instead. This takes us to an insanely straightforward consequence that is cost reduction.
This will only be timelessly true if your boilerplate is constantly maintained, though.
2 — Continuously updated developers
As developers, we are by nature in a permanent state of research and discovery, so all our code should be as well. Any boilerplate should reflect a permanent exchange of ideas over new, deprecated, or overall changing technologies.
While, at a first glance, it appears that having to constantly maintain a codebase is more of a necessity, it truly depends on the developers’ approach to their professional growth, to be honest. An updated boilerplate is also an excuse to be in the loop about the latest trends for the pertinent tech stack. And who doesn’t love to better oneself?
3 — Common sources of knowledge
Even if the conditions don’t require starting a project from scratch, having a reference codebase to rely on will help us find the solutions to long-pondered problems. The discovery process should be bidirectional, and anything learnt on existing projects can be poured back to our boilerplates as well. It also makes it much easier for new members to integrate in their day to day what the team’s practices might be.
At least in the circle of developers that we like to surround ourselves with, contributing to a common goal and learning from each other’s experiences is an extremely valuable emergent property.
4 — Coding identity
Surely, this soft skill is by far the most underrated value provided by projects such as this, but it’s very important nonetheless. Any boilerplate should be the result of many hours of meetings, discussions, exchange of ideas. Basically, many hours of interaction and working jointly with other people, learning to listen and contributing in a way that maintains everyone’s productivity. Thanks to this, the end result is a product that reflects dedication, commitment and hard work; it’s a brand with which everyone involved feels identified.
This identity is an advantage not every software studio has. Every time there is a need to move developers to a different project, onboarding times shorten and, therefore, cost is reduced. We share code standards and practices, so everything is already familiar to us.
The weak case against boilerplates
You will probably find some conflicting sentiments online around the usage of boilerplates.
For instance, it could act as a black box that keeps junior developers from really understanding what’s going on behind curtains. The way we see it, this also should not happen because any developer that strives to learn and grow professionally will inspect how the codebase works under the hood simply out of curiosity.
Another very common argument against boilerplates is that they have high maintenance needs, or higher complexity than necessary due to excessive features. Neither of these reasons are strong enough. Ideally, any repository needs to be maintained, regardless of its nature. This is mandatory. Maintaining code is what keeps it alive and fresh, not a duty. Excessive features, on the other hand, should not happen if we scope a boilerplate with practicality, only including features that are required in most projects.
It’s worth mentioning that boilerplates are useful and valuable when the company aims to build a specific type of project. In these cases, there is a certain go-to tech stack frequently used. For instance, at Loop, we are experts at building monolithic architectures composed of a Rails API and a React frontend. Even though every project is designed depending on their specific product requirements, this is the combination that we recommend most times. That’s why it makes sense for us to have boilerplates of these technologies ready to use.
And even for projects that have the same tech stack, as Agilists we understand that the architecture of a project should not be built upfront, but instead should develop organically according to its specific needs. While we understand that any product should unfold over time as features change, there is a basic architectural foundation needed to cover our Definition of Done as a company. And this is what we choose to include in our boilerplates.
In a nutshell, the pros of working with boilerplates outnumber their arguable cons. And we choose to make use of their extensive value by creating our own. Our boilerplates are the result of a vast learning process and experience from repeating common features over different successful projects. Authentication, internationalization, analytics, performance optimization, continuous deployment, you name it. Last month, we made them open source so everyone can freely contribute and make use of it.
You can find them here:
