We know that our customers see our service as a critical part of their infrastructure, and this is a responsibility that we take seriously. Unlike other software-as-a-service companies, we don’t have the luxury of hoping that a customer will notice an issue and report it or try again later. CodeGuard provides an automated service and for customers that rely on us for daily backups, that means that we have a 24 hour window, 365 times a year where we have to perform at our very best. Our process for developing and maintaining the service has to reflect that reality.
Just as we have scaled our service to accommodate hundreds of thousands of website and database backups on a daily basis, we’ve had to scale our product development process to consistently deliver high-quality results for our customers while maintaining the 99.99% levels of reliability we have achieved. We can’t haphazardly release features or change functionality without thoughtful preparation, focused execution and thorough testing.
What does this look like?
It can vary slightly from project-to-project depending on the components involved, but we generally follow an Agile-based workflow. As a result, the entire team participates in every phase of the project from brainstorming through maintenance.
Brainstorming allows everyone the opportunity to share ideas and get everything out into the open. These discussions are not structured and often cover topics from from high-level deliverables to specific implementation details. Not only are they helpful for getting good (and bad) ideas into the group consciousness, they also serve as an opportunity for everyone to reach a common understanding of the project at hand, any potential complexities and options for execution.
After brainstorming, we move on to planning. This is a very important, but often incredibly difficult part of the process. The high-level product goals have to be deconstructed into small enough pieces for an engineer to build. Knowing how small or large to make these units of work and how to estimate their size relative to the other units of work in this project can be a tedious exercise. Make the pieces too small and it’s difficult to adjust the plan as new information arises and divide the work amongst the team. Make the units too large and you may end up waiting for a big piece of functionality to be completed which delays progress on other components. How this process works exactly will vary greatly based on the composition of personalities on your team. For us, it’s usually a spirited discussion that lasts two or three hours every other week. The result is often flow charts of functionality and a plan with the individual units of work.
As an engineer, this is the most fun part of the product development cycle. Everyone on the team starts implementing the items that were defined in the plan. We meet formally every morning to talk about progress and areas that we need help, but there is constant communication within the team during the day. During this process, we often work in ad-hoc pairs to get through the more complex bits of functionality or in cases where we are modifying existing components related to our core backup or reporting systems.
In addition to automated unit testing and functional testing, we also do a lot of team testing ahead of releasing new functionality. Our service connects to a wide variety of hosting providers, platforms and server types. As a result, we are extremely suspicious of the software that we build. Having humans devise test scenarios and directly interact with any new features we have built gives us an extra level of assurance that we did not miss anything in our automated testing. For functionality that requires user interface changes, it also give us the opportunity to make sure that everything works as expected in all of the popular browsers.
5. Deployment and Maintenance
Unlike other development teams, once we’ve built a new feature, thoroughly tested it and agree that it is ready for release, we can’t just give it to the client as say that it’s finished. We have to deploy the changes to all of our customers and maintain all of the functionality that we build. This reality of being both the development and operations team makes us very cautious about how things are implemented. If you know that your phone could be the one ringing at 2am when something breaks, you’re going to think twice before modifying code that you don’t completely understand or writing a super-clever, elegant, one-line and completely unreadable piece of code.
I believe that this process, which represents our intentionality, intense focus and commitment to delivering a high-quality product to customers is one of things that sets us apart from other backup solutions. An open-source plugin may have had more developers looking at the the source code, but the ultimate responsibility for ensuring that a backup runs every day is still up to you, the website owner. And, what about those times that you inevitably need assistance? Community support is a wonderful thing, but is it the best option for mission-critical infrastructure services?
These limitations do not apply to CodeGuard. Our service isn’t free, but that is because we have a team of professionals that are dedicated to the success of your backups. Every CodeGuard customer has a whole team working for them to ensure that their backups happen as scheduled and we have developed a process that allows us to do that while continuing to improve and add features to our service.