This is a guest blog post by Adil Aijaz, CEO and Co-Founder of Split.io.
Like writing, software development is a creative and iterative process. Our code is like a story, and the more we edit the code, the better it gets. Passing work on to an editor lets us take a step back, and it provides us with an outside perspective. No matter how good our first draft is, most of us could almost always benefit from some editing.
This need is even more acute in the world of continuous deployment (“CD”). Software teams face the pressure of moving faster to deliver better products and build an edge over competitors. Paradoxical as it sounds, you can’t move fast without putting systems and processes in place to apply the brakes. You need to be able to pause to revise and improve your work.
It always helps have another set of eyes on a creative project. Here are three suggestions on how to bring external editors into your development process: design reviews, code reviews, and controlled rollout.
Start with a feature design review
For any new project, start by drafting a one-page summary that lays out the what, why, how, and when of your project. The one-page limit, while arbitrary, is important: it helps you focus on the bigger picture. Now post this on Confluence and invite colleagues to a ‘Design Review’ meeting. The more cross-functional the review team the better.
The goal of this meeting is not to design by committee, it’s to gather feedback on your design. Remember, the editors don’t write for the author, they help the author refine their draft. If more than one meeting is required, whittle down the number of participants in subsequent meetings to one or two people for more focused editing.
Expand the code review process
As you write code, get frequent feedback from colleagues by using pull requests in Bitbucket. The benefits of code reviews are many: from catching bugs to mentorship of new engineers. To get the most out of code reviews, try the following guidelines:
- Avoid giant code reviews. Be incremental. It is easier to edit a chapter than a book.
- Make code reviews mandatory. Optional code reviews do not happen.
- Publish code review guidelines. Develop a team consensus on what is good code.
- Reward good code reviewers. Code reviews should be part of performance evaluation.
Used controlled rollouts to create a customer review process
Design and code reviews get your code ready for production, but there are still some big unanswered questions. Will customers like your work? Will your code throw up an unexpected performance problem that could bring down the site?
You can avoid all of these concerns by using Controlled Rollouts (“CR”). CR is the practice of deploying code to production, but being selective about which of your customers are exposed to it. Taking a CR approach allows you to gather more feedback before your widest audience experiences your finished product; in short, you can turn a portion of your user base into editors, too.
It’s easy to control rollouts through the use of feature flags, or simple on/off switches coded into your release. Let’s use a quick code example to illustrate the principle here.
Say your project is a new algorithm that recommends products to customers. Here’s how the feature flag might direct access to your feature:
if flags.isOn(‘user-id’, ‘new-recommendation-algorithm’) { return new_recommendation_algorithm(‘user-id’); } else { return old_recommendation_algorithm(‘user-id’); }
The flag is a class that evaluates whether a user is able to access a feature or not, in this case giving users either the old algorithm or the new one. The criteria used to make that choice can be configured by something as simple as a file or database-backed configuration, or a more complex distributed system with a UI.
At Split, we use controlled rollouts to slowly introduce new code, and we start by only exposing new features to our internal employees. As new work progresses through development, engineers ask each other for feedback, and the rest of the company becomes an ad hoc QA team as they engage the new capability.
With that round of editing accomplished, we’ll then whitelist the feature to a few key accounts: maybe the customer(s) that requested the feature, those who prefer being on the cutting edge, or our newest customers and trial users. We’ll get feedback from this first true user cohort through direct outreach, and by watching monitoring metrics for machine performance changes that could be correlated to rollout.
Finally, we’ll slowly ramp this feature to our entire audience, usually going from a small percentage of users and accounts to every customer over the course of a week. Again, we continue to monitor machine-level metrics to gauge the performance and experience of the group in aggregate. Over time, we’ll look at our engagement analytics to see how the feature is fairing. If a problem shows up anytime during the rollout, we can kill the feature by reducing exposure to 0% of customers, thus avoiding emergency fixes.
Customer editing through these controlled rollouts ensures that your final product is a masterpiece. If you’d like to get started practicing controlled rollouts, feature flags (on/off switches for code) are a great way to begin. You can check out open source feature flagging libraries (e.g. Waffle) for your language(s) to start down the controlled rollout path, or my company, Split, provides controlled rollout as a service—adding data and insight to the rollout methodology.
Software development is a creative process, and like other creative pursuits, your output can get better, faster, with the right editing.