3 Reasons Why Boilerplate is Rarely Reused • Slash

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.

Table of Contents

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!