21 Mar

A new chapter

A new chapter

Having spent the past two plus years in the consumer space at Good Eggs, my first week at LaunchDarkly has been an absolute whirlwind experience. From getting acquainted with the development process to meeting our amazing team, the on-boarding process has been, albeit daunting, very warm and welcoming.

Getting up to speed

As part of getting up to up to speed in my first week, I’ve been diving in to the stack. John has been a fantastic pair and resource for not only the current lay of the land, but also providing valuable historical context around the product’s evolution. I still have a lot to learn, but am feeling better equipped every day.

Back and the future

Before joining the team at LaunchDarkly, I was particularly impressed with the product and its evolution. Feature flagging, to me, permeates beyond a software development process to defining how organizations—really people within organizations—work together to deliver the best possible experience to the end user. After seeing how LaunchDarkly works from inside and with its customers, I’m happy to report that I was not only right, but there is so much more to it!

I’m looking forward working on this empowering, impactful product with our incredible team and can’t wait to be a part of LaunchDarkly’s future.

14 Mar

My Agile Launch

Starting at a company that helps software teams release faster with less risk has reminded me of my first foray into agile development.

One of my earliest professional experiences was as an intern at HBO, where I reported directly to the VP of Emerging Technologies.  Over the course of the summer, it became clear that there were more promising new technologies to explore than there were engineers.  The undaunted college student that I was, I convinced my boss that I should own one of these projects.  Every day I would demo my work on a screen in his office, and he would provide feedback.  A few weeks later the VP presented to senior management and the company officially green-lit the project.  Though we didn’t refer to it as such, that cycle was my introduction to Agile.  Yet more importantly, it was a daily routine where a non-technical business stakeholder provided direct feedback to a technical resource; an arrangement that I’ve come to realize is quite uncommon.

Working at large and small companies in a variety of engineering roles, there are two overall trends that I’ve identified:

  1. Companies often separate engineering from the business side.
  2. Most development-related failures (e.g. missed deadline, bad or buggy feature, release causing a security vulnerability, etc.) are a result of miscommunication.

Neither of these statements are profound in isolation but when coupled genuinely pique my curiosity.

Over time the broader engineering community has developed numerous tools and processes to mitigate risk.  Missing deadlines?  Use story points to measure team output (velocity) over time.  Releasing buggy features?  Try test-driven development.  Want to avoid downtime during a release?  Setup application performance monitoring in your staging environment.  While these “quality assurance” measures are not guarantees of perfection, they make development more predictable.

Problems arise when we cut corners in response to misaligned expectations.  Let’s say there’s a feature request for a relatively straightforward user enhancement.  The development team has done everything right to this point (features properly designed and scoped), but towards the end of the sprint the team finds a scalability issue with no clear path forward.  Engineering management notifies the business side of this issue and insists that there should be resolution within five business days.  Five days pass and the developers have made no progress.  Engineering rushes to fix the issue through a refactor but skips unit testing to release earlier.  Two new bugs slip into production.  Instead of working on the next sprint the development team now works to get a hotfix release out.  One unexpected event can change everything.

The separation of the business side from its engineering counterpart sets the stage for frustration and missed opportunities.  Any tool that can bridge the gap between these two groups offers immense value to an organization or a working relationship.  Cucumber, a Behavior-Driven Development test tool, empowers non-technical stakeholders to define requirements, in plain English, that double as executable test guidelines for engineers.  By regularly reviewing Cucumber test results, a business stakeholder could easily assess the current status of a project.  Nevertheless, Cucumber facilitates one-way communication and offers no clear guidance on iteration or state.

The daily iterations I had at HBO were extremely effective in moving the project forward quickly. In a perfect world we could repeat this process as often as possible with senior management to win their approval as early as possible.  What if we schedule a daily meeting with the entire senior management team and show up with a buggy build?  It would quickly become apparent that our good intentions are far less valuable than executive time.  Instead, what if we gave each one of the senior managers a version of the technology that we could push updates to over time?  What if I could focus on building features and my boss could choose and deploy the ones that he thought were ready?  What if after realizing that there was a problem with a deployed feature he could hide that feature without involving me?  LaunchDarkly does all of this at the enterprise level.

To me LaunchDarkly is about much more than feature flagging or even quality assurance; the platform empowers companies to reconnect the technical and non-technical departments in order to shorten feedback cycles with customers and make better decisions.

This mission is a game changer.

That its founders and team are all extraordinary yet humble makes the opportunity twice as appealing.

07 Mar

What Feature Flagging Management and a 4x Super Bowl Champion have in common

Recently our investors, SoftTechVC, had a panel with professional football players on “unleashing the elite” – how professional athletes need grit, determination, hustle and mental toughness to push themselves and their teams to the next level. The panel with was captivating and amazing. The pros talked about their unrelenting training schedules – the long hours not just working out, but studying game films and memorizing plays. They talked about sacrificing college parties, time with friends, time with their families, as well as injuries. Was the sacrifice worth it? Yes, they said. They were providing a better future for themselves and their families.

RonnieLott

Ronnie Lott visits SoftTechVC

After the panel, a friendly guy named Ronnie introduced himself and asked me about software development trends. I’d graduated from Harvey Mudd College, statistically amongst the worst football teams in the country, and Ronnie had graduated from USC as an All-American. Ronnie said my eyes lit up as we talked about whether software would soon be layers of AI building on AI. I said just as 20 years ago players didn’t have iPads to watch game film on, 20 years from now we’d be amazed at the technologies that software was using.

Then I wondered why football players were at a VC firm. Because they were investors in SoftTech. The money that Ronnie, his son, and the other players had hard-won on the gridiron was going on to fuel the dreams of entrepreneurs to build a better way to build software. I thanked Ronnie for his support of LaunchDarkly, and I hoped to return his trust in us. And in the meantime, as a down payment, he could have a LaunchDarkly t-shirt.
The first LaunchDarkly investors were literally myself and John, my-cofounder, putting our own money in. Then it was our colleagues who believed in us.  Even now that we have institutional investors, behind our institutions are still people, investing because they believe in us. Thanks Ronnie Lott, Malik Jackson, Duane Brown, and all the other investors in LaunchDarkly.

03 Mar

Launched: Feature Flag Variation Editing

LaunchDarkly Feature Flag Variation Editor

Feature flags are powerful when serving variations like true and false. However, they are even more powerful when you can serve variations that are strings, numbers, JSON objects, and JSON arrays — which we call multivariate feature flags.

Previously, we allowed you to create multivariate feature flags with defined variations, but we did not let you add, edit, or delete variations once they were created. Now, you can!

With support for edit variations, you can now edit feature flags after they are created.

You can now:

  • Manage pricing in an e-commerce app by serving number variations
  • Dynamically control configuration values
  • Serve hex values to control CSS styles
  • Sunset variations that are no longer necessary

Editing Variations

When you navigate to any feature flag, you will notice a new Variations tab. This is where you will be able to edit your flag’s variations.

For boolean flags, you can edit a variation’s name and description, but not the value. This is because boolean flags can only serve true and false values.

LaunchDarkly Feature Flag Variation Editor

For multivariate flags, you can now add, edit, and delete variations even after the flag is created. Moreover, you can edit any variation’s value, name, and description. Keep in mind that you cannot change the “type” of variation being served after the flag is created.

LaunchDarkly feature flag variation editor

When you add, edit, or delete a variation for a multivariate flag, the change will apply to all environments within that project. For example, if you have a feature flag called “Checkout Flow” with 4 variations: A, B, C, D and you deleted variation D, then every environment will only have 3 variations (A, B, C) for the “Checkout Flow” feature flag.

We’re excited to deliver this new feature to you and would love to hear your feedback at support@launchdarkly.com.  You can reference our docs for more info.

01 Mar

Implementing Feature Flags in an Angular E-commerce App

E-commerce applications can take on many forms. Whether they’re retail, goods exchange, or an auction website, online commerce is becoming more common than offline. Modern front-end frameworks, such as Angular and React, provide the tools necessary for creating fast and responsive single-page e-commerce apps. In this article, we’ll delve into the process of using the LaunchDarkly JavaScript SDK to introduce new functionality in an AngularJS e-commerce application.

E-Commerce + Real-Time Feature Flags

With the growing demand for quicker, more reliable releases, development teams should consider having feature toggles in their toolbox. The user-facing nature of web stores facilitates the perfect environment in which feature flagging promotes granular control and feature visibility.  Some of the use cases include:

  • Rolling out storewide discounts with minimal overhead
  • Gradually rolling out new checkout and payment systems and assessing performance and revenue impact before fully rolling out
  • Allowing customers to personalize their shopping experience
  • Serve promotions and recommend items based on a customer’s preferences and previous behavior

Having these implementations wrapped in feature flags creates a safety net for catching even the smallest discrepancies, such as outdated seasonal discounts and conflicting pricing rules.

Using Feature Flags in an E-commerce Environment

Feature flags prove to be incredibly valuable in an online store. In such a fast-paced environment, product pricing is constantly changing, with various discounts and markdowns being put into effect. We’ve created an open-source Angular application (based on Code Project’s ShoppingCart) demonstrating the power of feature flagging in an e-commerce application. In our app, we implement a multivariate feature flag named “store-discount” which returns a number indicating a percentage discount on all products.

Integrating

To integrate LaunchDarkly feature flags with our Angular app, we will need to begin by creating a service which will initialize the LaunchDarkly client. Using Angular’s $q dependency allows us to return a promise which will resolve when the client has prepared its initial set of feature flags.

Now, our main controller can use our newly defined LaunchDarklyService to initialize the feature flag client, and save it in the application’s root scope (a set of data available to any page in our app) once the client is ready.

Also, the controller starts a listener within the LaunchDarkly client to change the current value of the store’s universal discount whenever a flag is modified. This allows the app to dynamically render new information. In our case, prices are slashed, and a notification pops up, alerting the user of “amazing new discounts!” This is achieved by using an ngIf directive to slash through the original price, if a discount has been applied.

Here is a video showcasing our completed multivariate flag in action:

Try it out

This demo was built on top of Code Project’s ShoppingCart, and the code is available for your use on GitHub. You can checkout the JavaScript SDK functionality here.

—-

Primary Contributor:  Arnold Trakhtenberg, Engineering Content Consultant at LaunchDarkly

17 Feb

Day 1: Let’s get down to data

After five months of backpacking with my partner through Scandinavia, Southeast Asia, and Africa, I wasn’t confident I would be able to rejoin the crazy world of tech. I knew that being part of a dynamic startup with a product and team I believed in would help.  Coffee would too.

What drew me into LaunchDarkly were all the demographic ‘wins’ – a great product in a growing space, a strong, savvy team, and outstanding team of investors. Plus, as an audiophile, I love the To Be Continuous podcast, which features Paul Biggar of CircleCI and our very own Edith Harbaugh.

That was enough to start the conversation, but here’s why I signed on to LaunchDarkly:

  • Right time, right place: For me, LaunchDarkly is at its Goldilocks moment. With a 16-person team, a technology that developers love, and a growing list of happy customers, the startup appeared poised to (pardon the pun) launch. But as the gears click into place, it creates a huge amount of operational fun in order figure out how to get it all done. Is it time to bring on more sales reps? Are we ready to move out of our excellent home at HeavyBit? Most importantly, does it all scale? To all of the above, an emphatic ‘yes.’ The fun part is figuring out how it all comes together.
  • You know nothing Jon Snow: In startups and in coding, I’ve found the best way to build is through experimentation. You come in with a thesis for how you believe the world works, but the hard truth is that you can’t count on knowing anything about what your customers want. And when in doubt, you test. You set up experiments with a small set of customers to see what sticks and acknowledge when it doesn’t. In startup land, this build-and-test culture has become the norm. But even as development cycles contract, code deployments are often a nail-biting all-or-nothing push. Enter feature flagging, which enables developers and product managers to stage deployments as a series of manageable chunks. In short, feature flagging lets us course correct even as we race ahead, and I love that LaunchDarkly enables that.

So how did it turn out? As of day 1, my expectations on the team, product and customers were right on. The snacks, however, were even better.