3 reasons why boilerplate is rarely reused

I think it’s time for a short discussion on the good ol’ Boilerplate; more specifically, why it’s rarely reused. Have you ever wondered this? Or perhaps you’re thinking, “Boilerplate, wait what?” The boilerplate is, in short or perhaps theory, sections of code that are integrated into a variety of places with little to no variation. Think of a standard “about us” page that uses a very typical statement which is often copied and replicated verbatim a variety of other places. Now that definitions are out of the way, let’s get into it.

Diversity of needs & technologies

As a tech organization, we use various technologies to build for clients and often the needs and complexity of our projects differ. This naturally makes reusing a boilerplate a moot point. For example, we have a boilerplate for ReactJs using JavaScript that we think is reusable for other projects. Yet low and behold one day, a client requests the Typescript version which requires us to create one.

In another case, we were using ReactJs with Typescript version, but we were using a normal REST API call. However, again specific client needs and requests throw us a curveball. The client’s technical team says their API requires a GraphQL client in turn requiring us to adjust the boilerplate to support that. Of course, if there is no preference, we can stick to what we originally built as a boilerplate, but often the outcome is not satisfactory or to our standards.

I imagine you’re beginning to see the pattern here. Software development is not a one size fits all situation. Each client brings their own unique needs and requirements to the project and the team must react accordingly which all but negates the reusing of boilerplates.

Too many or too few reusable parts

In boilerplate we tend to include many aspects we believe beneficial and we may use for instance pieces of code, but often things do not always go as we anticipate. Therein lies the challenge of balancing between too many or too few reusable parts. For example, similar to the above example, boilerplate has REST API support as the API connection, but it prefers to use GraphQL client to connect instead; therefore, it still requires changes.

Another approach we can take is to keep everything simple, nothing overdone; include only the essentials for structure. Sounds good, no? Yeah, if it sounds too good to be true, it likely is and this case is no exception. If this approach is taken, whenever we need to implement a reusable feature, technical or other that we used to implement before, we still have to copy-paste or rewrite those pieces of code again.

Even something like common SNS logins: i.e. Google, Facebook, etc. seem like good things to keep as they’re common requirements across a multitude of projects from various clients. Then your next client comes along and says, “Uh yeah, no thanks. I only need a mobile number login feature.” Now your nice piece of code for that SNS login is no longer valid, oh well. This code now needs to be removed as leaving unused code in the structure is never a good thing.

Hence, trying to anticipate what the client may require is a fool’s errand, akin to playing darts while blindfolded, as your time can be better spent more productively. So you’re thinking, “Well why not just use a streamlined, thinned out boilerplate that you can easily add to?” Touché, though again you’ll run into problems. Perhaps your boilerplate did not include the logic for SNS logins and now you need it; copy & pasted or worse, rewritten which takes time.

Outdated dependencies or architecture pattern

Outdated dependencies need to be maintained. If we are relying on ReactJs as a frontend framework library, we will employ one of its versions when building the boilerplate; for example, React 14. However, if we fail to utilize the most recent version with included changes, and we want to use the same boilerplate 3 months after the previous build, we end up with a plethora of obsolete dependencies. These dependencies signal numerous warnings and sometimes require migrating most of the boilerplate with the old library version to adapt to the new method.

In the same way we maintain the architecture pattern; for example, MVC (model view controller): model referring to the database, view referring to how the data is displayed to the user, and controller referring to how you control the logic and manipulate the data. This was previously the most popular framework pattern roughly four years ago. However, now clean code architecture is the most used and appreciated pattern. We still need to constantly adapt and improve to whatever changes occur within the ecosystem.

The key takeaway here is that your boilerplate, though well-crafted and effective for your current project, will more than likely not be reusable for a variety of reasons. Trying in vain to dial in the perfect boilerplate that can be easily reused is honestly time poorly spent as the odds are not in your favor. Although, fret not for you are a development master so forge forward confidently with your new boilerplate!

Promsopeak Sean Nuon
Sean Promsopeak Nuon
Lead engineer
Sean is technology-driven and passionate about working with technology that helps people. Now he finds himself as an executive member of Slash, executing the technology operation side from an entrepreneurship point of view. He has over 9 years of working experience dealing with technical problems, project management and team mindset building. He splits time between Solution Architect & Lead developer for enterprise clients and as part of the management team, he helps build future-proof architecture, define quality standards, team culture, and hiring & training practices.
In this article

Explore more resources

5 Things to Consider When Choosing a Mobile App Development Partner in Singapore
5 Things to consider when choosing a mobile app development partner in Singapore
Discover essential tips for choosing the perfect mobile app development partner in Singapore. Learn about expertise, portfolios, communication, technology, and value to ensure your app's success.
6 minute read·
by Henry Panhna Seng ·
June 21, 2024
AI prompt engineering
AI prompt engineering techniques: the power of crafting effective prompts with special prompt formulas
Learn the art of AI prompt engineering techniques to maximize the potential of generative AI. Discover effective strategies and tips to craft precise prompts for optimal AI outputs. Explore advanced solutions at Slash's Generative AI Solutions.
7 minute read·
by Kevin Yin Seng ·
July 15, 2024
Skip to content