Ideas
The Starter-Kit Strait-Jacket
Author:Eric Müller
Date:September 20th, 2016

You have an idea for an application and are ready to build. Money is tight and time is short, so you decide to use a starter-kit to get the job done. It seems like a great idea: someone else has already taken the time to put together a complete application — from database to server components to browser side code — which should save you money and let you focus on writing the code that is unique to your application. What could possibly go wrong…

Of course, the promise does not always live up to the hype. It’s weeks or months later and you are still struggling to get your project out the door. The starter-kit that offered so much at the beginning of your project has now become a major roadblock.

We have seen a number of projects use starter-kits, and have seen the same problems repeatedly. The biggest problem is that a starter-kit is often built to solve someone else’s problem. Unless you have the exact same challenges as the starter kit author, you will very likely be in a position where you are either delivering something sub-standard, or be forced to strip out pieces of the starter-kit. Once you start to tug on a thread, you can’t be sure how much will unravel.

Many of starter-kits have limited or no documentation. The more complex a starter-kit, the harder it can be to figure out what is going on under the hood. Because of the build process, you may not even know everything that is in your final application. Maintaining or enhancing the code base also becomes challenging in this situation.

Required versions of core components are also a major pitfall. Examples include applications built on the most cutting edge (and unstable) version of Node, or PHP applications that use deprecated functions. When using older components, your application may include security holes that can’t be fixed without doing major refactoring of the underlying starter-kits. Applications on the bleeding edge version of a component may include functions that are removed as the component moves into a stable release cycle. Again, you are locked into a platform that will become increasingly difficult to maintain over time.

As illustration of this, we were asked by a client to modify an application that was based on a popular starter kit. Although the initial work was completed in a very short timeframe, they had run into challenges with extending the work. The default file structure made it very difficult to create reusable components. In addition, the framework was tied to a non-LTS version of Node, which meant the work would have to go through a lengthy migration to get it onto a more stable platform. After a thorough analysis, it was determined that the best path forward was to rewrite the code so that it was no longer tied to this starter-kit.

Also consider that the more complex a framework or starter-kit, the tighter the strait-jacket. Meteor, for example, allows for rapid development as long as you are fine with using Mongo as a data repository. While Mongo is a great solution, it is not the correct answer for every problem. We have seen plenty of junior development teams start with Meteor. As they mature as a team and learn more about data management, they realize they need to move to a relational database. They are now faced with a hard choice: rebuild everything from scratch, or figure out hacks to keep the system going.

Starter-kits also take away an opportunity for learning. Instead of taking the time to explore new technologies and ideas, the developer is given a bunch of code and directions on how to change superficial elements, such as the user interface or the database connection.

However, this doesn’t mean that starter-kits can’t be useful. Creating your own starter-kit can accelerate your development efforts, particularly if you do similar projects on a regular basis. Starter-kits from other developers can also provide an opportunity for a bit of digging around to see what other folks think is important to include as the foundation of an application.

Starter-kits always come with a trade-off. While they allow for code to get out the door in a very short timeframe, they often force limitations that are felt when it comes time to add key features to an application. The more complete starter-kits are — by their very nature — more complex. The key question: is getting off the ground quickly worth the trade-off in flexibility to meet long-term product needs? Unless one is crafting a simple website, the answer is almost always no.