Fiscal year 2023

Other formats

This direction and our principles were introduced in the 2022 Digital Product All-Hands on 2/22/22. You can view the recording of that presentation or download the slides if you like.

In recent years, Norton engineering practices have matured through the introduction of product management, scrum processes, and well-managed and highly independent product teams. This has been complemented by the containerization of our applications to improve the reliability and availability of our applications at scale. But with that growth has come growing pains in the form of accumulated application and infrastructure complexity and process overhead that can result in lost velocity.

These are critical issues to address this year in order to ensure that we can meet Norton's broader customer commitment:

Simplest access to the best content

And specifically, Engineering can have an outsized impact on providing "simplest access" because:

• The more time we spend dealing with system complexity, the less time we have to remove barriers to access and improve the experience of our customers.
• Underlying system complexity is often indirectly felt by customers. For instance, complexity can lead to slow performance, unexpected restrictions, or complex user flows, all of which limit our ability to provide simplest access.
• Lost velocity due to process overhead slows our ability to deliver customer value and simplify access to our content.

Addressing complexity and lost velocity will be the main focus of Engineering's two primary goals for this year: reducing complexity through migrations and capturing lost velocity with automation.

Reduce complexity through migrations

Sometimes it's easier to build a new ball of yarn than it is to unravel the old one.

As engineers, we have two strategies to pay down technical debt and reduce complexity in our systems: maintenance and migrations. Maintenance focuses on paying off debt while keeping the system intact, whereas a migration is a complete rebuild followed by a "rewiring" phase where connections are moved from the old system to the new one and then the old system is removed entirely.

We should be maintaining systems that are still solving the problems they were designed to solve and migrating when a system is no longer solving the right problems for us or when the cost of maintenance is so high that there's no time left over for new development.

Note

Good systems are built to solve very clear, very immediate problems, but because technical debt naturally accumulates over time and problem spaces naturally change over time, sometimes even the best systems eventually need to be replaced. This is not a reflection of the system's design or quality, nor is it a reflection of an engineer's skills in any way—it is a simple reality of change and growth.

Gaining competence with migrations will help create a path forward where we feel more confident in our ability to manage complexity growth. This will free us up to focus more on what matters: delivering value to our customers. "Gaining competence" might include:

• Building a better personal or collective sense of when it's appropriate to migrate systems instead of maintaining them.
• Designing processes and tools to help complete a successful migration.
• A conceptual shift—change of our mental model for systems—that incorporates migrations as a potential solution.

As the owners of technical details, we feel the pain of difficult-to-reason-about systems more immediately and more acutely than many of our colleagues, who depend on us to raise a flag. But migrations are not the sole responsibility of engineers, and it is expected that we will need to work closely with other stakeholders in the Digital Product group to ensure that migrations are successful.

Scope, intent, and tips

Migrations are applicable to all of Engineering—Development, DevOps, and Engineering Management. Code, technical designs, tools, and infrastructure can all be migrated, but there may be other technical areas that could benefit from migrations and this is not meant to be an exhaustive list.

The intent is not necessarily to complete migrations—though that would be ideal—it is to reduce complexity by better knowing when to resist the impulse to maintain a sunk cost and to enable engineers to think outside of the box of existing systems when proposing new solutions.

Here are some tips and additional resources to help get started:

• Essential reading: https://lethain.com/migrations/.
• A migration isn't done until the old system is entirely removed, so make sure those steps are given equal weight and planning. Some examples of these steps include shutting down servers, archiving the codebase, or deleting a namespace from Kubernetes. We aren't responsible for defining all the steps, but we should coordinate with others to find out what they are and see things through to the end.
• If migrating the whole system isn't viable, implement and follow a deprecation strategy to migrate function-level or code-level elements. See the design system's deprecation strategy for an example.
• Other Norton engineers are critical stakeholders and users for almost all projects and infrastructure. To ensure a successful migration, they should be included early in discussion of technical designs and migration planning and when it comes time, they should have clear documentation and tools they need to migrate with minimal friction.

Capture lost velocity with automation

Clear processes and roles help us work better together. And while scrum ceremonies that help align our teams and goals are critical to the success of our products, they can come at the cost of valuable engineering time. Put more simply, added process can result in lost velocity.

To help capture some of that lost velocity, we will seek to automate manual processes and communication.

Not all automation is good

The best automation replaces a well-defined manual process. Automation that does not do this will be brittle, feel unhelpful, and garner a general distrust in automation.

It is therefore critically important that any team-wide automation efforts be well coordinated, scoped, tested, and carefully rolled out to teams.

CI/CD

A central feature of our plans for automation this year will be highly visible continuous integration (CI). CI is a well-established process of automating code and software checks (sometimes called "quality checks") that is designed to reduce the cost of errors by creating a much shorter feedback loop, allowing teams to fail faster. This ultimately leads to greater confidence for the whole team through better visibility of our work's status.

Once confidence is high, we will implement continuous delivery (CD) to automate the deployment process while still retaining a final check before deployment. An effective CD strategy has more dependencies than CI, so we will carefully evaluate solutions and design deployment strategies that work for everyone. Accomplishing a complete CI/CD pipeline will require input and work from DevOps engineers and application engineers, and will impact teams beyond engineering.

Other forms of automation

In addition to CI/CD, we will be looking to identify other manual processes that are good candidates for automation. Here are some opportunities to explore:

• Tooling that automates day-to-day tasks.
• Tooling that helps move documentation closer to the code.
• Automatic provisioning and destruction of environments via infrastructure as code.
• Automation that improves the quality of life for team members outside of engineering.
• Setting up hooks to critical sources of truth such as Jira, Teams, and SharePoint so that we can spend more time in the code and less time in issues, chat threads, and documentation.