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.
Baiting the Hook
We landed a project for One Medical immediately following the conclusion of a large, Wagtail-based project for PATH, and based on their comparable needs, we thought a similar tech stack might be appropriate. We made our case to One Medical, and they decided to go with Wagtail as well.
In the early stages of building the One Medical site architecture, we saw the potential for several elements of the structural code (configuration files for Docker, continuous integration, webpack, and code that passes data from back-end to front-end) to be abstracted and used on other projects, eliminating tedious cutting and pasting. This gave rise to the idea for a starter kit: a single repository with a working deployment pipeline and front-end components for projects like One Medical.
We formalized the idea by setting specific goals for the starter kits:
- Eliminate (or at least expedite) the set up and dev-ops portion of a site build
- Increase efficiency by leveraging existing code from past projects
- Allow our design, strategy, and dev teams to wireframe with basic components that could be used in a real environment, in real time, and with real content
- Get to the heart of design and development sooner on new projects by having common, working code at the outset
- Help clients save money by requiring less time and (potentially) fewer resources for development, and gaining a competitive advantage
- Improve our own lives and increase our own happiness
With our goals in place, we set about creating a starter kit that would use abstracted code from One Medical as a jumping off point for the next project that required a similar stack. We tasked a handful of developers (one of whom is an avid fisherman) with the preparation of a starter kit codebase. We met several times as a team to determine which features should be abstracted into the codebase, and even brought in a producer and ticket board to stay on track. The fisherman gave this endeavor a name: Albacore.
Casting Our Line
The final stack for Albacore is Wagtail, Django, Lambda, CircleCI, Docker, Vanilla JS (ES6), and SCSS. Albacore includes a foundation of base models and components that we often rewrite for each project. For example, there are fully functional, tested, accessible, and responsive components for:
- Full width images
- Side-by-side text with image
- 2 and 3 column card grids
- Link lists
- Accordions
- Carousels
- Videos
Soon after we completed the initial stack, we got the opportunity to put it into action; a brand new project matched Albacore’s purpose. We copied over the Albacore repository during the initial project setup and began modifying it to fit our client’s requirements. Though there was a significant change in the deployment of the stack, it was clear early on that pulling from a solid, working base of code within a single repository had greatly increased our efficiency. Within a few days we had the stack up and running in a useable local environment.
The Catch
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.
Reeling It In
Despite some wrinkles, the creation and use of the new starter kit was successful enough for us to assemble another, separate starter kit, Barracuda, built on a completely different stack (Contentful, React/Typescript, Netlify). The process gave rise to internal discussions about the long-term maintenance and true purpose of starter kits. Developers wanted to update the dependencies and potentially swap out some of the tooling within the kits. Violet Peña, an Associate Technical Director, said:
These issues and others will keep coming up as our offerings and tools evolve. As it is, any updates will be ad hoc depending on who has free time and an opinion. This means that project teams can’t rely on starter kits reflecting current tooling and architecture decisions, which decreases their effectiveness. It feels like this requires concrete owners for each starter kit, so those people can be held accountable for maintenance and enhancements.
So who gets to decide what work is done on a project vs. in a starter kit? In my opinion, assigning an owner and turning the starter kit into a software product would defeat the original purpose and intention. The kits were created to provide a starting place for similar projects, not a continuously updated, project-specific springboard. How valuable is a starter kit if you have to spend the first few weeks of your project updating the codebase? Is it easier to start from scratch? These are the questions we’re still trying to answer.
Gone Fishin’
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?
