Just How Practical Are Starter Kits?
The start of new development projects at Instrument always leads to discussions about efficiency. How can we get through the opening stages more smoothly and quickly than last time? Recently, we’ve been weighing the benefits of using a foundational codebase, or starter kit, to commence development, as opposed to starting from scratch. This article will take a look at the successes and challenges starter kits have presented at Instrument since we began using them.
Initially the starter kit was successful, but as soon as we had a clearer definition of design and componentry for the new site, a few cracks started to show in the system.
The developers at work on the new project weren’t the same group that created Albacore, and this led to some confusion about how the components were built and how they functioned. More than one developer felt it was easier to scrap the front-end components in Albacore and start over, but doing so meant sacrificing a key aspect of the stack that had been tested for functionality and accessibility. We ended up redeveloping existing Albacore components to meet new requirements.
We also wound up dedicating time to the removal of Albacore-specific code that the new project didn’t require, and to ensuring that the final client codebase only had code that the new site would utilize. Albacore, it seemed, had too many features at the start.
Many people contribute to the evolution of ideas at Instrument. Albacore and Barracuda were created with specific goals in mind, and we did our best to stay flexible and open to change when some of those goals weren’t met.
The kits worked successfully during initial project phases when they matched well the specific technology and tools our clients preferred. And our efficiency definitely increased when we didn’t have to write AWS, Docker, continuous integration, and webpack configurations at the outset of every engagement.
Where they fell flat was in the need for continued maintenance, full comprehension of their features by developers, and time spent cleaning up for delivery. In the future, we may institute ownership for each stack so that, as far as which features are included and how often the kit gets updated, the buck stops with someone specific. We may also remove most (if not all) of the front-end portions of the starter kits and leave only the devops and data throughput portions intact, as it’s clear the time savings are in those areas.
All in all, the exploration of starter kits has been a fascinating phase of our ongoing quest to efficiently commence projects while maintaining the highest possible level of quality.
If you or your team is thinking about using starter kits, begin by considering the following questions:
- What’s the purpose of your starter kit?
- Will the starter kit be updated continuously?
- If so, how? And by whom?
- How much time should be allocated for maintenance?
- Does it make sense for your starter kit to have an owner?
- If not, who decides which enhancements get ported to the starter kit from individual projects?
- Have you allocated time to clean up the code from the final repository that you didn’t end up needing?