For many small businesses, one dedicated developer is enough. The application is small enough that one person can reasonably maintain all of the different components and deliver fixes and features fast enough to satisfy their users.
However, small development teams carry risks that can be subtle and disruptive. What if your team lacks the skills needed to grow your application? What if your team suddenly leaves?
8th Light has helped numerous companies prepare for disruptions and transition to a more sustainable and maintainable workflow that protects their business. In this article I want to document one of the main risk areas we look for, and the steps we take to help businesses protect themselves from it.
What if your team suddenly loses access to your software?
If only one person has access to your software system, and only that person understands how that system works, your business faces an asymmetrical risk that could quickly turn into catastrophe. Even if your team stays together, critical hardware failures could cause your entire team to lose credentials and access to the system.
8th Light helps businesses mitigate these risks by implementing four practices that distribute ownership and knowledge: system access, documentation, version control, and testing.
System Access
Our first step when working with small teams is to protect the business from the worst case scenario: losing access to your product. We make sure multiple people can access their software product, which includes the codebase itself, hosting services, cloud services, and other infrastructural components that bring your product to the world. This also includes training non-technical stakeholders how to access this infrastructure so they can hand it over to a new developer, designer, or technical lead if needed.
We follow this same principle by building redundancy into our own team. We ensure that both our clients and the teams that work with them have at least two people with access to all components, thus reducing the risk of losing access if anything were to happen to any one contributor.
Documentation
It is common for codebases with a limited number of contributors to have little or no documentation. Each of the contributors already knows the steps required to set up and contribute to the system, so documenting those steps seems unnecessary.
While clear and up-to-date documentation might not have a noticeable effect when things are operating smoothly, writing down details — like the required software, version numbers, and commands that run the application and its tests — is a quick and easy step that will dramatically reduce the time and effort required for a new developer to ramp up on the system in case of an emergency. It will also serve as a helpful template for your application as the system — and your team — grows.
Version Control
Version control tracks the changes made to a system over time, and provides a number of benefits for teams of all sizes. Some of its most powerful features won’t reveal themselves until your team grows and more developers need to contribute to the code at once, but even its most basic functionality can have a profound impact on your codebase and your ability to respond to crises.
As a ledger of all changes to your software, version control serves as a kind of roadmap for developers to learn how your system got to be in its current state. They can review this history to work backward and isolate specific changes to the codebase that are likely responsible for new features or bugs. It also helps bring focus on areas that have changed most recently or most frequently.
In an emergency, effective version controlling also allows developers to quickly “roll back” to a previous version of the system, before you began encountering problems.
Testing
After establishing a baseline of system access, documentation, and version control, the biggest impact we can have on a small team's codebase is creating a robust test suite. If there are no tests, we begin writing them. If the system already has tests, we review them to ensure they are serving their intended purposes.
Tests should give developers confidence to make changes. They are a layer of protection that alerts developers if the software is broken, or no longer functioning the way it was intended. When developers add new features, or tweak the code to work differently, tests assure them that those changes didn’t create a ripple effect of changes to other parts of the codebase. Best of all, tests give us all of this information before any faulty code is pushed into production and is discovered by users.
Robust and comprehensive tests also serve as additional technical documentation, augmenting the application’s explicit documentation by offering insights into the developer’s intentions when creating the system.
Conclusion
In uncertain times, each of these practices serve an important role in helping protect a business from unknowns. They address risks that rarely show any symptoms when small teams are working in harmony.
8th Light has helped numerous clients protect their teams, their software, and ultimately their business from these risks. Let’s talk — we will walk you through an audit and determine whether a software partnership makes sense for you and your team.