DEV Community: Dawn Parzych

Building better software with the scientific method

Dawn Parzych — Wed, 23 Dec 2020 17:16:29 +0000

I remember learning about the scientific method many years ago. Watching the Neil DeGrasse Tyson Masterclass, I started thinking about how the scientific method applies to delivering and supporting software. One quote jumped out at me: "The most important moments of your life are not decided by what you know, but how you think." It's not about what we know about delivering and deploying software, but how we think about the processes we use to do so.

As humans, we are constantly faced with problems. We build software to solve problems. The features we create sometimes have problems when we deploy. We encounter an obstacle and need to figure out how to overcome it. We don't necessarily know how to solve the problem at the outset, but how we think about the problem and the solution will impact whether we are successful or not.

How do you approach a software problem?

Imagine you're trying to compile newly written code and encounter an error. You don't immediately know what is wrong; we need to investigate the issue. How do you approach the problem?

Option 1: Delete all the code and rewrite it?

Option 2: Examine the error message, debug, review the code, consult others for help?

I'm hoping most of you picked option 2. When we encounter a new problem, we take a step back, think about the problem, and if we can't solve it on our own, we ask for help.

Whether you know it or not, you are likely using portions of the scientific method when solving problems. Science is about breaking things down into smaller pieces to gain a better understanding. The scientific method is a defined set of steps to follow before, during, and after an experiment.

Isolate a particular process
Form a hypothesis
Create an experiment
Produce repeatable results
Share your knowledge with others

We'll dig into each of these with a semi-fictional example. At LaunchDarkly, our main dashboard page originally listed all flags created in the system. As our customers began creating more flags, this resulted in performance issues with the main page loading. We isolated the performance issue to a large number of flags loading. Problem identified, process isolated.

Creating an experiment

Now to create a hypothesis. A hypothesis is a provable statement that can be answered by an experiment. A hypothesis isn't a question. It's a prediction or an explanation of behavior. Hypotheses generally start with research questions, such as:

Will adding pagination increase page load time for users with a small number of flags?
Will pagination improve performance for users with a large number of flags?

These are good questions, but they aren't hypotheses. A good hypothesis should be specific and seek to answer a single question. This requires concrete goals that can be measured. We can convert these two questions to hypotheses:

As a result of adding pagination, customers with fewer than 100 flags will see no significant difference in page load times.
As a result of adding pagination, customers with more than 100 flags will see a significant improvement in page load times.

Now, these hypotheses are ok. The problem is they aren't concrete. How do we know what significant means? A slight change gives us better versions.

As a result of adding pagination, customers with fewer than 100 flags will not see page load times increase by more than 5%.
As a result of adding pagination, customers with more than 100 flags will see page load times decrease by at least 10%.

These hypotheses are concrete, specific, and measurable. Now we are ready to create an experiment. Experiments help us make a discovery or test a hypothesis in a controlled manner. We run experiments all the time with software. We experiment when we test in production, conduct A/B/n tests, or run game days.

We identified two customer segments for our experiment, those with over 100 flags and those with under 100 flags. We can now enable a flag and collect page load times for these users. When experimenting, you need repeatable results. Having multiple customers in a segment ensures the results are not an anomaly.

The final aspect of an experiment is sharing the knowledge you gained with others. In addition to sharing the information internally, consider writing an article, or giving a talk.

If you're ready to start using the scientific method and experimenting—great! But before you go off, I have a word of caution. Beware of your biases.

Beware biases

One critical aspect when using the scientific method is to be aware of your biases. When crafting a hypothesis or experiment, you need to think about how your biases frame your thoughts. You don't want to construct an experiment that forces the "right" answer.

For example, there are two biases you might encounter when building software. The first is the anchoring bias. We rely too much on the first piece of information we receive. Everything else gets interpreted from this vantage point. When creating a hypothesis or experiment, make sure that you don't anchor everything on the first item presented.

Another bias is the Framing effect. We decide on options based on whether they are presented in a positive or negative light. If your hypothesis is framed positively or negatively, does that influence whether you see it as a success?

The next time you look to add functionality or troubleshoot an issue, take a moment to think about how you can use the scientific method to structure your thinking.

10 capabilities developers need in a feature management platform

Dawn Parzych — Mon, 26 Oct 2020 17:14:51 +0000

Design and development phases with a feature management platform

We've written a lot about the build vs. buy decision. If you decided to buy instead of build, what are some of the capabilities you should look for? As a developer, you need to consider how feature flags come into play during the various phases of building a feature—design, coding, testing, and releasing. Think about what are the must-have features and which ones are nice-to-have during each of these phases.

Design phase

We believe you should start thinking about using feature flags at the design phase. The decisions about a feature made during the design phase can help you determine how to configure targeting rules for the feature and how to test and collect feedback on a flag.

Broad SDK support
Parts of your application may be written in different languages. You're going to want a platform that supports all the languages you code in. Having a wide variety of SDKs at your fingertips, in a single platform, helps you choose the best programming language for your features. Don't limit yourself to a single SDK or deploy multiple tools to cover all your SDKs.

Experimentation
As you are designing a feature, there may be questions about the best way to proceed. What if you ran an experiment to collect evidence, instead of trusting your gut? Having data to support a design decision can save hours of work having to refactor code or start over from scratch.

When experimenting and designing in general, you need to collaborate with other teams and team members. Sharing information on experiments with product, customer success, or support is an essential part of running a successful experiment. Look at what types of collaboration and access is available to people outside of the development organization.

Build and testing phases

Granular targeting rules for developing and testing
When building a feature, you likely want to deploy code to production early but limit access to only yourself or your team. Targeting a single user or group of users based on a variety of attributes gives you the flexibility and peace of mind to deploy code to production early in the development phase to test out the design. You want to be able to test your features in production without releasing the feature to everybody.

Safety & security
Testing in production can be a scary thing. How do you ensure you aren't making changes to the wrong flag or environment. Feature flags are not only used during the build process. They're also used for operational purposes and to manage entitlements. You need to make sure you can't accidentally disable or change the wrong flag. As a developer, you want administrative access to test, staging, or dev environments, but when it comes to production more restrictions ensure no surprises when a flag is accidentally toggled. There's no need to live in fear if role-based access control (RBAC) grants or restricts access to resources within the flag management platform.

And when something does go wrong, you need detailed audit logs to see what changes were made and by who for a given environment. Audit logs can help you quickly identify whether a recent flag change resulted in unexpected behavior.

Release phase

Targeted and percentage-based releases
Not all features release to production in the same way. Some features target specific groups of users; others can be released more broadly. You need the flexibility to release features in a variety of ways. For example, if you're rolling out a new currency conversion feature, you want to target users in select countries. But, if you're releasing a new home page, you may choose to release to a percentage of all users. And speaking of targeting, you want the ability to target users based on multiple attributes, either pre-defined or custom.

Schedule release progression
Releases may not always happen when convenient to your schedule based on time zones or scheduled time off. Scheduling changes to targeting rules for future dates and times means you don't have to plan your day/week/life around a scheduled release.

Automatically disable a flag
Releases don't always go smoothly, sometimes things fail. When a failure occurs, you want to limit the blast radius and get that feature turned off as quickly as possible. When monitoring and observability systems detect that critical thresholds have been passed, you shouldn't have to wait for a person to disable the flag. Integrations with observability and monitoring tools to automatically trigger a flag upon an alert can stop a situation from impacting more users.

Launched

A feature isn't done until the code for the feature flag has been removed. Nobody likes it when technical debt accumulates. Look to see what functionality exists to help you identify and remove flag code from launched features.

Filter relevant flags to reduce the accumulation of technical debt
If your company has many flags, you need a way to quickly filter through and find relevant flags when addressing technical debt. Filtering all flags by status, you can see which flags have not rolled out to all users, which flags are permanent, and which flags can be safely removed.

Configure Slack reminders
One way to make sure flags don't build up in your codebase is to get reminders and notifications sent to the tools you use regularly. Having your feature flag platform send you a message when a flag's status becomes launched, or inactive provides a helpful reminder to remove the flag.

Find all flag references in your codebase

Knowing a flag needs to be removed isn't the same as remembering all the files that reference the flag. Ensure you can integrate your flag platform with your code repository to see which files refer to a flag quickly. With this, you won't accidentally miss a file containing a reference to a flag.

No matter the size of your team, or where you are in your DevOps journey, there is a lot to be considered when choosing the right feature management platform.
This list can help you make an informed decision and make sure you don’t forget critical aspects.

To learn more about feature management for developers, check out our recent post, Build: The First Pillar of Feature Management.

11 Tips for Migrating to LaunchDarkly

Dawn Parzych — Tue, 04 Aug 2020 16:27:45 +0000

How to safely move from your current feature flag system

This article provides a roadmap for how to effectively migrate to LaunchDarkly’s feature management platform. This is the third article in our three-part series on building vs. buying a feature flag management system. Part one focused on what is needed to build your own solution. Part two presented questions you should ask to determine if you’ve outgrown your existing solution. This final part provides guidance and tips on conducting a migration from a homegrown or open-source solution (OSS) to LaunchDarkly.

Challenges of migrating

Moving from one technology to another isn’t always a smooth process. I recently upgraded my cell phone. The migration and upgrade was a frustrating process. First, I got frustrated with my current phone; once that frustration reached a tipping point, I got frustrated with the phone choices, then the upgrade process, and so on. Migrating from one feature flag solution to another can be filled with similar frustrations, but it doesn’t have to be if you follow the tips below.

Some potential challenges you will need to prepare for when migrating from a homegrown solution to LaunchDarkly include:

Addressing technical debt
Prioritizing migrations across teams
Training team members

Engineers who learn the benefits of feature flags will eagerly create them but be far less eager to clean them up afterward. As a result, you may have hundreds, even thousands, of flags by the time you migrate. Migrating these would be an overwhelming task. What’s the best way to address this technical debt? Even better, how can you avoid accumulating more in the future?

You may have deployed multiple solutions to address your feature flagging needs. Whether this was due to different teams building their own solution, or needing different OSS for multiple languages—you need to think about how to migrate all of these.

Teams and departments need training on how to use LaunchDarkly. New accounts need to be created, new processes set up, etc.

You’re going to have challenges when you migrate, but overcoming those challenges will be worth it in the long run. We’ve grouped these tips into three categories based on when they’ll come into play: Planning, Migrating, and Fixing.

11 tips to help you migrate

I’m sure you’re itching to start your migration and dive into things. Before you do, take five minutes to read the rest of this article for more tips. It’s better to get all the information ahead of time and set yourself up for success from the start, instead of trying to fix things later. Jumping in too soon is one stop on the way to accumulating technical debt.

Divide your migration into three phases: planning, executing, and post-migration. During the planning phase, you determine what is needed and how the migration will occur. The execution phase consists of putting the plan in place. And the post-migration phase covers how to go forward with day-to-day use.

Tips for planning

1. Plan a gradual migration

There’s no need to rush with the migration or the audit. Often customers will run their old and new systems in parallel. If you have a feature currently in the middle of a rollout, or you’re running an experiment, leave those running on the existing platform. Set up new flags in LaunchDarkly. It’s ok to run systems in parallel for a couple of months while things wind down and your teams are trained. If you do it the right way, you may be able to avoid giant cut-over steps and downtime.

2. Keep manageable timelines

Treat the migration as a continual learning process. As the migration progresses, you’ll learn more about how long each step takes. You’ll also find that some steps vary wildly from team to team and are much harder to estimate. Revisit and adjust your estimates regularly to keep stakeholders informed. Be prepared to change the placement of teams and projects in the schedule.

3. Choose the right team for the pilot

If your engineering organization contains many teams, start with a single team rather than trying to migrate all teams and their projects at once. You can focus your attention on helping one team rather than spreading it across many. This project to migrate a single team, known as a pilot, is aimed at producing useful techniques and tools that other teams can use.

Pick a team that won’t be under pressure during the pilot. If the team is about to start a new project in which it can use LaunchDarkly, or if there’s a maintenance period coming up between projects, both of those are suitable situations for a pilot. The team should be ready to provide regular feedback on its migration process, as well as assisting in the creation of lightweight migration tools and documentation to be used by the rest of the organization.

Tips for migrating

4. Standardize a naming convention

If you didn’t already have a naming convention or style guide in place for feature flags, take this opportunity to create one. As feature flag use grows in your organization, having a naming convention to identify which team owns a flag, what release it is associated with, and the purpose of a flag is useful.

Things to consider when creating a naming convention:

Be descriptive. Verbose flag names are better than brief flag names.
Use prefixes with a project name, team name, release, or other identifying elements.
Specify whether the flag is temporary or permanent.
Include a creation date for the flag to help with flag cleanup.

Change is hard. Following these tips and using LaunchDarkly’s customer success team will help you get the most out of your migration.

5. Keep most of the legacy flags in the legacy system

As I mentioned above, technical debt is one of the biggest challenges of migrating. How do you migrate potentially thousands of flags safely? You don’t. Take this opportunity to start over. When I upgraded my phone, I didn’t automatically reinstall all the apps. I only installed the frequently-used, work-related, and important apps. The rest I ignored. When it’s time to migrate feature flags, we recommend using a similar process.

How do you migrate potentially thousands of flags safely? You don’t.

Look at your flags. Identify the permanent and operational flags. Which of those are still used, still needed? Configure those in LaunchDarkly. You don’t need to—nor should you—migrate all your flags to LaunchDarkly.

6. Add new flags to LaunchDarkly only

You want the number of flags in the legacy system to only go down. If the team has to create new flags while migrating, those flags should only be created in LaunchDarkly.

You might wonder: if the team’s existing code is only looking in the legacy flag system, how’s it going to see the new flags? That’s covered by our next tip…

7. Change the wrapper, not the calls

The legacy flag system probably provides an API module. It contains flag evaluation functions that are called throughout the team’s application code. Instead of changing all the application code that uses flags, leave it as it is. It’s much easier to change the implementation of those functions to use both the legacy system and LaunchDarkly.

We use the term wrapper to describe the changed functions because they wrap an existing API specification around a more complex implementation. Internally, the new implementation evaluates flags by querying both the old and new flag systems, and uses whichever flag it finds first. The order of querying is set by a dedicated “flag evaluation mode” flag, kept in LaunchDarkly.

When the new wrapper is deployed, it should look to the legacy flag system first. Once the team is comfortable with LaunchDarkly, and the most important flags have been migrated, you can switch the flag evaluation mode to query LaunchDarkly first.

8. Divide into projects

Projects, which are the primary organizational containers for flags, should be created at the start. We recommend creating a separate Project for each app or executable owned by a team. Learn more about Projects in the LaunchDarkly documentation.

Tips for post-migration

9. Define your process

There is no magical way to prevent technical debt from accumulating, but there are some things you can do to minimize it. First, define what done means when it comes to a feature. When you create a flag, what processes do you have in place for ensuring the flag is removed? Is a feature done when it rolls out to 100% of users, or is it done when the flag is removed from the code?

Coding a flag is a two-part process: creating a flag and removing a flag. These should not be considered two separate processes. We recommend submitting a pull request to remove the flag at the same time you submit the PR to add it.

If you don’t follow this process, LaunchDarkly provides code references to help you identify where in the codebase the feature flag is referenced for easier removal.

Looking for more information on how to reduce technical debt? Check out these blog posts.

10. Use tags

If you only have a handful of tags, it’s not time-consuming to find a flag in LaunchDarkly. As your number of flags grows and more teams use feature flags, this becomes harder. Tags help you organize and sort flags into groups.

For example, if you have flags related to experiments you can create an ‘experiments’ tag. If you have flags for specific departments, you can create a tag with the department name. These tags can help you control which team members can read, write, or modify a flag.

Before migrating, brainstorm a list of relevant tags. You can always add more tags later, but try to limit the number of tags to make things easier to find.

11. Ask for help

When migrating, you shouldn’t go it alone. Thankfully, you don’t have to! LaunchDarkly’s customer success engineers are here to help you get up and running. We also have self-learning options through our step-by-step guides. There’s no need to reinvent the wheel; learn from others and make modifications to suit your individual needs.

Conclusion

A successful migration consists of planning, and then executing on the plan. Diving into the doing without a solid plan in place can result in the accumulation of technical debt, or problems with the migration. Take your time to review these steps, work with your customer success engineers, and you will be on your way to a successful migration.

Have You Outgrown Your In-House Feature Flagging Tool?

Dawn Parzych — Tue, 04 Aug 2020 16:26:48 +0000

In a previous post, we discussed the pros and cons of building your own feature flag management system versus buying a commercial, off-the-shelf solution. If you fall into the former camp and have built something internally, how do you know when you’ve outgrown that solution?

As your organization grows, you’ll inevitably outgrow tools and solutions. This doesn’t mean you made the wrong decision to build something. It just means you’ve grown.

As companies grow, their needs change. For instance, what once made sense as a side project for an individual contributor may no longer be feasible for a single person to support.

This article helps you determine if you’ve outgrown your in-house feature flag management system and whether it’s time to explore alternatives.

How has your application changed?

Companies typically use multiple languages in their applications. Can your solution adapt to the addition of new programming languages in the application stack? How many languages do you need to support? What are your plans to add support for more languages?

Is there a need to run client-side vs. server-side? Client-side flag evaluations and data can provide useful information for targeting or running experiments, but it also increases security concerns, risk, and complexity. Opening connections from the client-side resource to the server requires authorization and implementation of security measures. If your user base is geographically diverse, a content delivery network (CDN) may be needed to help with latency.

How will you support multiple use cases across multiple teams?

When you started, a single team was using a handful of flags to separate deploys from releases. Now, other departments want to create feature flags. Operations and site reliability engineers (SREs) want to use flags as circuit breakers and for load-shedding. Product managers want to run experiments. Sales and Customer Support want to manage entitlements. These new use cases require access control and permissions for safety and security purposes. They need additional functionality.

Operations needs:

Audit logs to see flag changes across the organization—who made the change, when the change was made, and why.
Integrations with existing tools to toggle flags programmatically or kickoff other workflows. For example:
- When performance thresholds are passed, certain flags should be toggled to deliver a lighter version of the page.
- Adjust logging levels programmatically when an alert is received.

Sales and Product Management needs:

Multivariate flags to define multiple options that a flag will serve for running experiments.
Advanced targeting rules to control who does or does not have access to certain features. This includes creating segments and target groups based on specific attributes.
Flag prerequisites and relationships to control groups of features.

Customer Support needs:

Troubleshooting tools to know which variation a user was served to troubleshoot issues.

All teams eventually need:

Access control logs to restrict access to their team’s flags and ensure only authorized people can toggle a flag on or off. Can you run the risk of somebody editing a configuration file and accidentally deleting a flag?
Reporting and insights on the flags served. What percentage of users has the feature been rolled out to? How are targeting rules or new variations impacting the number of evaluations?
An intuitive user interface to toggle flags on and off. You don’t want to give everybody access to a config file or a database. Other departments will require a user interface to control and configure their flags.
A solution that scales with increased page views and greater numbers of flags being toggled.
An organization-wide dashboard to display the flags, what’s enabled, a flag’s purpose, and a point of contact for each flag. This helps control technical debt and manage the use of flags across the organization.

How will you support multiple feature flag systems?

If you have multiple languages to support, you may need to deploy multiple solutions as they are often language-specific. Without centralized feature management, different teams may build or deploy a solution that meets their business needs. How many feature flagging systems is your organization able to maintain?

Given that many feature flagging tools are language-specific, the more languages your application uses, the more tools you’ll need to support it. In addition, other teams may choose to implement solutions to meet their experimentation or testing use cases. The more solutions you have with similar functionality, the more confusing it is to those supporting and configuring them.

Is maintaining an in-house feature flagging tool worth your time?

According to the 2019 State of DevOps Report, elite software teams use a combination of proprietary tools, open source, and commercial off-the-shelf software. Low performers have the highest concentration of proprietary software. While there is value in building your own tools, it comes at a cost.

When you made the decision to build vs. buy, it made sense to divert your engineers from building core product features to build and support the internal feature flagging tool. Now, it is time to re-examine those decisions. Ask yourself again, “Can I afford to divert engineers from building core features to build features for our internal feature flagging tool?” Times have changed; that answer may be different now.

From the time you decided to build your own feature flagging system to now, your company has grown in size, and customers are requesting more features. You need more engineers to keep up with this rising demand.

Do you want those engineers to devote all their time to maintaining an in-house feature flagging tool, or would you rather have them creating new stuff that drives revenue? Will investing in this tool hold you back from meeting your quarterly or yearly goals? If you aren’t in the business of feature management, devoting valuable time, resources, and people to supporting internal tools may no longer be in the company’s best interest. Some of our best customers originally built an internal solution and later decided to buy, allowing them to focus on what they do best.

How will you scale?

Feature flags should be lightweight. Adding flags should not result in exceeding performance budgets and breached service level agreements. What is the acceptable latency of a flag triggering, and how can you deliver this at scale? (See the point on CDNs above.) What infrastructure is needed to ensure system reliability, and what is the cost of that infrastructure?

When the system was originally designed, did you opt for a pushing or a polling architecture? Will that scale, is it worth it to re-architect the system? As more flags are added to the application, the size of the payload sent to the user increases. Larger payloads can result in poor performance or delays with flags propagating to users. Building a robust infrastructure to support feature flagging on a larger scale can be an expensive undertaking.

What to do next

Growth is good. If you’ve outgrown your internal solution whether due to expanded use cases or wanting greater control over the release process, it is time to invest in a commercial solution. Using the requirements above, determine your must-have features to help you select the best feature management platform for your organization.

If you’ve decided it’s time to migrate off your homegrown solution, be sure to check out the third installment of our “build vs. buy” blog post series. We’ll walk you through the ins and outs of migrating to a commercial feature management platform like LaunchDarkly.

#ToggleTalk 3: Resiliency

Dawn Parzych — Fri, 17 Apr 2020 18:23:44 +0000

According to Merriam-Webster, resilience is defined as “an ability to recover from or adjust easily to misfortune or change.”

Toggle thought this topic was a good follow-up to last week’s conversation about productivity. We are currently having to adjust expectations about what being productive is. We’ve had to adapt to new remote working situations quickly. Systems are being pushed to the limits as large numbers of people quickly moved to cloud-based solutions for meetings, social gatherings, and educating students. How well you adjust to these changes requires resiliency.

Questions we posed on resiliency:

How do you define resilience?
How do you build resiliency in your systems?
How do you increase your own tolerance for disruption and failure?
What value can we derive from critical events?

Highlight reel

Whole vs. parts

If you are looking for resilience, you have to look at the big picture. From a technology perspective, if you are striving for five-nines availability, you have to look not just at the technology but the people, the processes, and the organization as a whole.

Liquid error: internal

Sociotechnical models do just this and help when it comes to resiliency. Sociotechnical theory looks at the interrelationships between the social and technical aspects. Consider how people will use the software, who will be using it, who will be supporting it. This can help you build resilience as you adapt to the changing social aspects.

VisArch

@ruthmalan

@richburroughs @dparzych If we view our systems as sociotechnical systems, the boundary shifts — to include people, hence adaptive capacity.

21:17 PM - 15 Apr 2020

When looking at the social aspects, remember that resources are finite. And people are not resources. People do not have an infinite ability to respond to and recover from failures. We use metrics to track the health of individual elements of our systems. We can also use metrics to track our own health and ability to respond to failures.

Liquid error: internal

Humans are resilient, systems are robust

One aspect of resilience is sustained adaptability. This is where humans come in. People make decisions about what to build, how to build it, and how and when to change them. Systems will not adapt without humans. It isn’t possible to separate the human from the tech.

Liquid error: internal

Surprise!

I love the framing of incidents as surprises. It takes away some of the negative stigma of incidents being bad. If we frame incidents as surprise learning opportunities, it helps us figure out what the best response is.

Liquid error: internal

Mental models

The conversation about resilience and surprises seemed to naturally lead to a discussion of mental models. A mental model is an explanation of someone’s thought process of how something works. Mental models help us understand and interpret the relationships between things. When we encounter an obstacle, we may have to update our mental models. The solution that worked previously may not work the second time around. Our ability to continually update our mental models is part of our resiliency.

Liquid error: internal

Summary

During #ToggleTalk, we touched on all four concepts for resilience as outlined by David Woods (see article below):

Ability to rebound
Robustness
Extensibility
Adaptability

We need to look at technology from a sociotechnical perspective for true resiliency.

Thanks to everybody that joined in this week’s discussion on resilience. See you next week on #ToggleTalk!

Want more?

There is an upcoming conference (next week on April 21st!) if you want to learn more about resilience engineering and the process for building systems that can withstand unexpected failures. You can register here: FailoverConf (free of charge!). We will be there, and so will one of our Developer Advocates, Heidi Waterhouse.

Or you can check out these recommended reads and talks:

Recommended Reads
Resilience is a Verb

Four concepts for resilience and the implications for the future of resilience engineering

Report from the SNAFUcatchers Workshop on Coping with Complexity

Above the line, below the line

Recommended Talks
OOPS! Learning from Surprise at Netflix

How did things go right? Learning from incidents

A Few Observations on the Marvelous Resilience of Bone & Resilience Engineering

ToggleTalk 2: Productivity

Dawn Parzych — Fri, 10 Apr 2020 16:24:02 +0000

Productivity refers to the quality or effectiveness of the work we do. We want to feel productive, but different people are productive in different ways. At LaunchDarkly, our goal is to help teams build better software, faster. Essentially, we help people be more productive.

In choosing the topic for this week, Toggle thought productivity was the perfect topic. We are all having to reset expectations on what it means to be productive. They’ve heard a lot of people saying, “I’m not feeling very productive these days,” and they want you to know you are not alone.

Questions we posed on productivity:

What does productivity mean to you?
Tips on staying productive.
How are you most productive?
What gets in the way of your productivity?
How has your productivity changed in the last month? Are you still expecting yourself to be as productive as you were before?

Many people are feeling less productive as they are adjusting to remote work with room-mates, partners, pets, and/or kids. All while trying to maintain their physical & mental well-being. This takes a toll on your personal and professional productivity.

For me, I’ve been working remotely for years. But now it’s not just me at home, my child and spouse are home too. My productivity is not what it has been previously. I need silence to write. My house is rarely silent these days, it’s taking me longer to write (I’m grateful to my spouse for taking our son out for a walk so I can get some writing done today). I’m also taking daily breaks for parental duty which may look like making lunch, going for a walk, helping with school work, or doing an activity together.

Highlight reel

There’s a difference between productivity and busywork. Being busy is good, but don’t confuse that with being productive.

Liquid error: internal

Motivation and productivity go hand in hand. It can be overwhelming to think about how much time a project will take or how many items are on your to-do list. Getting started may be the hardest part. Here are some tips to help with that:

If working on a big project, set mini-goals. This gives you a feeling of accomplishment as you meet those mini-goals.
Create nested to-do lists. To-do lists tend to grow as you add more items. Each morning identity three things you must accomplish. Even if they’re low hanging fruit, celebrate that you achieved them.

Liquid error: internal

One thing that frequently gets in the way of productivity is distractions and interruptions. People may say they’re good at multi-tasking, but what they are really doing is context switching. Context switching comes at a cost. Let people focus on a task without interruptions.

Liquid error: internal

A common form of distraction is interrupt messages. Whether these messages are in Slack, email, text, or your brain telling you there is something more pressing you need to be working on. Silencing these messages can help you be productive.

Nathan Pearce

@pearcenathan

@kiran_oliver @dparzych Modern messaging systems are terrible offenders of destroying productivity. I think it's important to educate those around you that focus time means logging out of IM systems.

16:24 PM - 08 Apr 2020

A great way to reduce some of the context switching is to schedule breaks. You may think taking a break is counter-productive. It's not. If you schedule breaks to browse the internet, respond to messages on Slack, read a book or unload the dishwasher, those tasks aren’t distracting you during your focus time and give you a chance to recharge.

Nathan Pearce, the host of REDtalks.live videocast, shared a very cool example of a spreadsheet he uses to help him schedule focus time and breaks.

I love that the spreadsheet lists ideas of what to do during the breaks. This way, you can be productive on your breaks as well as during the focus time. Need some suggestions on ways to recharge during your breaks? Check out this list of Self-Calming and Self-Recharging activities from Harvard University.

Summary

Spring is here, the trees are budding, flowers are blooming (as so my allergies tell me). Spring sometimes triggers increased productivity as the sun is out for longer. This spring may seem a little different as we are adjusting to stay-at-home orders and the unique professional and situations this creates.

If you’re not working on side-projects, learning new skills, or baking up a storm - that’s ok. Do what you need to take care of yourself. Becoming productive at self-care still counts as productivity!

Thanks to everybody that participated and shared resources. See you next week on #ToggleTalk!

P.S. Want more information on staying or getting productive? Check out the resources below:

Tools and Processes

David Allen's GTD Methodology
Trello, Microsoft To Do, or good old fashioned pen and paper if you want to go non-digital.

Books

I encourage you to check out eBooks from your local library or look into purchasing from an independent bookseller.

SuperBetter by Jane McGonigal
The Miracle Morning by Hal Elrod
Digital Minimalism by Cal Newport
Essentialism by Greg McKeown
Making Work Visible by Dominica Degrandis

#ToggleTalk 1: My First Flag

Dawn Parzych — Fri, 03 Apr 2020 16:57:56 +0000

Our first ever #ToggleTalk was held on April 1st. It coincided with my 1st anniversary at LaunchDarkly. Therefore, we found it fitting that the topic should be “my first flag.”

Questions we posed:
What was the first flag you ever deployed? What method did you use to deploy it?
What do you know now that you wish you knew before deploying your first flag?
How have your feature flagging practices changed since your first flag?
Did your first flag work as expected?

My first introduction to feature flags came about eight years ago when I was a Product Manager at F5 Networks. With the waterfall methodology being used, feature releases were not common occurrences. Getting features into a release wasn’t always possible, so my team got creative. We decided to deploy the features behind a flag in a config file as early access.

Highlight reel

The notion of “invisible behavior” came up in response to the question, “How have your feature flagging practices changed since your first flag?” Invisible behavior includes things like database migrations, logging levels, things not visible to end-users but still essential for making applications run smoothly. We often think of flags for user-facing features or UX components, but their use doesn’t have to be limited to that. Flags can be used for infrastructure and operational tasks. Think about what invisible areas you can use flags.

// Detect dark theme var iframe = document.getElementById('tweet-1245429672470437888-991'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1245429672470437888&theme=dark" }

Some sage advice to those just starting with flags - don’t build and deploy flags in a vacuum. The flags you deploy may impact multiple business units. Remember to coordinate with others and get appropriate buy-in when necessary.

// Detect dark theme var iframe = document.getElementById('tweet-1245403886397132800-781'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1245403886397132800&theme=dark" }

Lessons learned

There’s a learning curve whenever you do something new. And hosting a Twitter chat is no exception. Thank you so much to those that provided feedback to help us make this stronger. We heard it was unclear whether we wanted people to respond to the questions posed.

Yes!

We absolutely want to hear from you. These questions are a jumping-off point to start a conversation. We want to know what you think.

Going forward, we will also provide a brief description of a term or topic for those new to a topic.

If you have tips or suggestions on how to make these better going forward, please don’t hesitate to send them along.

Join us again next Wednesday, April 8th, for the next installment of #ToggleTalk. Until then, safe flagging.

Introducing #ToggleTalk

Dawn Parzych — Mon, 30 Mar 2020 17:29:09 +0000

A new weekly Twitter chat covering feature flags, CI/CD, modern development, and more.

At LaunchDarkly, we talk a lot about our community. Our community is our customers. Our community is the people we talk with at conferences. Our community is the people who attend our Test in Production meetups. We decided our community needed a mascot that embodies our values. Our community is made up of all sorts of folks, and we want to represent all of you. Enter Toggle.

You may have seen Toggle at sticker tables, conferences, and meetups. All these events have kept Toggle quite busy, and they haven’t had a chance to properly introduce themself to the wider LaunchDarkly community. With Toggle’s travel schedule slowing down, it is time for their public debut.

Toggle’s mission is to help teams build better software. A part of that mission is to engage with the community. It is through our community that we as an organization:

Discover new use cases
Share ideas and best practices
Identify and collaborate with partners within the ecosystem

Our community is what motivates us to do what we do. When we look at Toggle, we see you.

Who is Toggle?

Toggle embodies what LaunchDarkly sees as critical elements of our community.

Toggle is curious. They love to explore.

Toggle is helpful. If you have a question they can’t answer, they’ll find somebody who can.

Toggle loves to collaborate. They enjoy hearing about your projects and finding ways to work together.

Toggle is empathetic. They want to make it safe for you to explore and learn.

Toggle is a champion for inclusivity. You may often hear them saying “You do you.”

Toggle has a great sense of humor. From puns to “dad jokes” to groan-worthy jokes—Toggle has a wide range of jokes.

Toggle is positive. They know that sometimes accidents happen.

Toggle appreciates balance. They embody LaunchDarkly’s value of“work is not life.” They know when to say no, and they don’t bite off more than they can chew.

Toggle is open-minded. They listen to others’ ideas and are receptive to feedback.

What is #ToggleTalk

As part of Toggle’s launch, we are kicking off a weekly Twitter chat called ToggleTalk. Each week we will post a discussion topic related to feature flags, modern development practices, CI/CD, or other topics curated by you, our community.

Here’s how it will work:

Tuesday, we will announce the topic and time of the chat via Twitter. This is your chance to provide questions related to the topic.
Wednesday at 9 a.m. PT and 3 p.m. PT we will host #ToggleTalk.

Please tag your responses using the tag #ToggleTalk.

Fridays we will post a blog with our favorite tweets, interesting tidbits, and lessons learned from the event, and Toggle will choose a random participant to earn some nifty LaunchDarkly swag.

We are so excited to share Toggle with you. We hope that you will celebrate with us on this journey and looking forward to seeing you online at #ToggleTalk!