Lightning Talks w/ Women of Scribd Engineering:

Migrations, Owning Quality, Instrumenting, and Finding

the Right Culture

Network: WeWork Password: -

@WomenWhoCodeTO
 WWC Toronto Team

Steph Betty Stella

Rebecca Bhavana Aileen Nahrin

Our Sponsors
HAVE YOU JOINED OUR SLACK GROUP?

Get updates first! Special giveaways on Slack

bit.ly/WWCTOSlack
Words from our Host
Green Field Projects, Or How I
Learned to Love Migrations

@WomenWhoCodeTO
Paige Stone
Software Engineer, Notifications
 Overview

Section One: CRM to CRM, Migration

Section Two: Flux, the Green field

Section Three: The big win!

 Change is Inevitable

Continuous Improvement, Production

features, growth, economics

How we levered a Migration to green field

a new email/notification system
 Paging Doctor Howard

● Overnight Updates On a legacy system, we tend to be surgical

● Deep nested Triggers in our fixes - the original system was
● High message lag architected over 5 years ago, and we’ve
● High dependency on Engineering been patching it ever since.
● Low Stability
● Low Velocity
 Enter: the Marketing Platform

● SQL ● Elasticsearch
● REST, SOAP, FTP ● REST
● List Segmentation ● Personal users flows
● Heavy use of timed queries ● Real Time Event driven
● Limited data per users ● Unlimited data per user
● Full featured Webhooks and Data
Feeds
Help from an Unexpected Place
 The Source of Truth

CRM -> Scribd

Scribd -> Iterable

The platforms are based on

different paradigms
 The Flux-Capacitor

Inspired by Flux Architecture (Action -> Dispatch -> Store -> View)
 Actions

Triggered Sends Triggered Events

● User forgot their password ● New sign up

● Send a referral ● Send a gift card
● Admin Emails ● Cancellation
● Dunning ● Unsubscribe from email/push
● Hard bounce
 Dispatcher

Sidekiq - Worker

Workflows

Call back via

- Webhooks
 Store

Iterable acts as the Store

-Object-Oriented database.
-Levering Iterable’s System events and Webhooks as callbacks.
-Our store listens for events via System events
-Events can also be triggered as well
 Views

Email as an extension of Frontend

-Treating email templates as components

 88 Miles Per Hour!

● Realtime Updates
● Common Sense Triggers
● Time to get messages almost massively improved
● Reduced dependency on Engineering
● Improved Stability
● Improved Velocity
 The Game of Marketing

Instead of doing User Segmentation, our marketers had to relearn how to develop
user flows, journeys, paths through the product. We can talk about gameplay, user
experience loops, and driving engagement.
 Back to the Future

Because everything is centralized components, it is now easier to switch

components out. It’s more generic. We can switch out components (Sidekiq to
Kafka?) without reinventing the wheel.

Additional data is trivial, Additional Events and Triggers are trivial

Less maintenance, means more Features!

Push Notifications, Localization, Improved Testing, Brand-Refresh, Data Analysis

Don’t go chasing waterfalls: owning quality
as a whole team effort

@WomenWhoCodeTO
Nikki Hernandez
Web QA Engineer
- Tester / professional guinea pig
- Agile tester, Scrummaster certified
- Self taught techie
- Mother of CAT, Tyler Purrden
- Lots of risk at the end of the
cycle
- Rushed testing (or building)
inherently degrades quality
- “Feast or Famine” cycles of
work
- Being isolate/silo’d leads to
tunnel vision or feature
blindness
- Build in quality from day #1
- Break down work meaningfully - MVP,
“Shippable Pieces”
- Limit tasks to 1-2 days
- Write small user stories
- Storypoint for non-dev work, external
dependencies, third parties
- Write and agree on Acceptance Criteria
- Agile teams work *together*
- Pair test, Pair dev, Pair design
Quality means more than just “testing”
- State the intent clearly, concisely - not the full flow
- Good: “Copy is translated in all supported languages”
- Bad: “User can select Spanish, view new copy on Saved page”
- Include happy path, and any other important considerations
(accessibility, locale, geolocation, exclusions, application security,
etc)
- Not a replacement for full regression tests, unit tests, or other tests
but may include some aspect of it
- Eg: “Performance: Page load time remains the same”
- A ticket isn’t done until the AC is
- Keep changes as isolated as possible
- Anticipate shared code or dependencies
- Keep ‘em separated - separate branches
- Quality code is:
- Clear, concise, stable
- Minimal in change and scope
- Is manageable, easy to code review
- Can be easily reverted
- Is testable in some way
- Communicated clearly! (MRs, to team, in tickets, etc)
- Identify the happy/golden path
- What do we want users to do?
- Identify negative path testing
- What will users actually do?
- What?
- Why?
- Real people with hopes and dreams (of
- Because we have our own biases.
using our products)
Utilizing personas allows us to
- Everyone has a unique motivation for doing
break out of that and try to
things the way they do
mimic real user behavior.
- A way to “put yourself in $X shoes”
- As a tool to support ad-hoc,
- How?
exploratory, usability, happy
- Build a real person. Give them a name, a
path, and edge case testing
job title, what’s up in their life right now?
- To see the site with new eyes
What are their motivations for using Scribd?
- To be able to test the full life
What brings them value?
cycle of a user as they cycle
- https://personagenerator.com/
through our products
- Testing user stories: Some generic testing considerations:
- Work with QA to prepare
- Is it accessible
some generic test scenarios - Responsive
- Setup staging environments, - Localized
sandboxes, etc - Check various platforms (desktop vs mobile,
- Test against your acceptance mac vs windows, ios vs android)
- Check various browsers: FF, Chrome, IE,
criteria
Safari
- Utilize personas to guide you
- Check various user states (if applicable)
- Exploratory / ad-hoc tests - Check various payment flows or methods
- Involve the whole team - Check the happy path
- Check for regressions where code was
touched
- Check metrics / analytic tracking events
- Owning quality means: - Testing for quality means:
- Planning for it from day 1 - Happy paths
- Work breakdown, sandboxes, how - Unit tests
to test, etc - Functional QA
- Writing quality specs, code, tests - Design / spec review
- Writing acceptance criteria - Pair testing
- Communication / collaboration - Exploratory / Ad-hoc usability testing
- Working small pieces at a time - Personas
- Advocating for the customer - Acceptance Criteria
- Working together! - Identifying high risk areas and testing
against them
By baking in quality from the beginning
you’ll:
- Mitigate risk or deadline slippage
- Build quality products
- Ship stable code often
- Be a lot less stressed
- Avoid mini-waterfalls
- Stay agile, my friends!
Instrumenting your Code for Great
Justice

@WomenWhoCodeTO
Katerina Hanson
Software Development Manager
● Self-taught Software Engineer
● Previous career as a chemical
engineer
● Love going and getting the $$
● Old Millennial - my memes are
old-school
● Measurements
● Quantitative data points
● Track the operation of
complex systems
● Visibility into the Health of
your system
● Give you insight into
performance
● Easy to read and understand
● Alerts you to new problems
● Helps with diagnosing
● Prevents flying blind,
wasting time
1) Database reads / writes
2) Calls to 3rd Parties (and response types)
3) Any important changes of state
4) Anything that may run out of space
5) Cyclomatic Complexity (if / else)
 Context is Important!

Is this users-over-time?

Or is potentially runaway queue?

Alerts
● Emergency
● Time-sensitive
● Actionable
● Demands Immediate
Attention
It’s Too Easy to set up Bad Alerts
● Limited Attention
● We get Desensitized, start
ignoring everything
● Lose the valuable alerts in
the Noise

BE PICKY
● #1 cause of Nuisance Alerts
● Outliers and drift will happen
over time.
● Alert only when the situation
is serious and actionable.
● Review periodically and
adjust
● SLA’s can be interpreted strictly
● Make sure they include
tolerances.
● These should be evaluated for
trends, and the work to address
scheduled and prioritize over the
long term, before it develops into
an emergency
● This is what an attack on an
endpoint looks like.
● Ideally, we’d have a circuit
breaker in the code that
would prevent this
● But a high level threshold
alert would be an ok backup
● Review your charts
regularly.
● View over different time
scales, see if you need
more info, or less.
● Make sure you have logs to
support deeper dives.
● Look for things you would
have liked to be warned /
alerted on, and consider
how to define your rules.
What you seek is seeking you : Find the
company and culture that is right for you

@WomenWhoCodeTO
Harini Iyer
Lead Software Engineer
LinkedIn: hariniiyer
Accidental Engineer
Point of No Direction
Self Image
Is being a good developer enough?
Turning Point
Should I quit?
The Magic Words : I don’t know (yet)!
Feedback
Culture can be influenced
But I don’t understand the product!
Scribd
 Company values

People

Accountability and Ownership

Love of Reading
 Engineering values

Refactor and Rebuild

Quality is everyone’s responsibility

Velocity
Building by Un-building
● AWS Migration
● MicroService Architecture
● Redesign systems
Scribd is Hiring!
Thank you
See you next time!
@WomenWhoCodeTO