How we killed our process, technology stack, and assumptions – and survived

Jason Lo(to @ MeetMe Corp. 2

Jason Lo(to


§  Applica(on Architect @ MeetMe

§  jasonlo(to everywhere! §  Spent 10 years doing credit card

processing ( PCI =( )

§  Now I’m in social ( =) )

So why are we here?


Learn how and when to change your

§  Processes §  Technologies When you have to change your

§  Product

Goals


§  Learn ways to successfully apply change §  Save yourself pain and suffering §  Spot warning signs before they become a problem

§  Dodge bullets


The Project

New Profile Page Overview


§  Exis(ng Product: Profile §  One of the most popular pages

§  Gateway to a user §  Lots of things happening §  Lots of technology

–  PHP, PostgreSQL, RabbitMQ, JavaScript libraries, messaging system

–  3rd party adver(sing dependencies, tracking systems

–  Lots of legacy stats, events, products s(ll in use

Rule #1: Develop One Product At A Time


A new product is just 1 new product. A rewrite is 2 products.

Samuel L. Jackson said it best…


“We have all the problems of a major theme park and a major zoo, and the computers aren’t even on their feet yet.”

– Dr. John Arnold, Jurassic Park



“They did it by making the single worst strategic mistake

that any sodware company can make: They decided to rewrite the code from scratch.”

– Joel Spolsky on Netscape



Some(mes you need to rewrite because you are adop(ng new technology for a new plaeorm or performance reasons.

Your ins(nct should be to reuse code.


Rule #2: Encourage a Minimal Viable Product

The Not-‐So Minimal Viable Product

† Thank you Thesaurus for helping me come up with vexing so I could make a joke with MVP using Mountain and Paper 13

So, you’ve been given a spec for an “MVP”, which apparently stands for a Mountain of Vexing† Paper.



If you want all the features of your old product, why are you rewri(ng it?



Less is More More opportunity to adapt to new processes

More (me to learn new technologies



Need help pruning features?

If a feature takes 1-‐month to build, would you delay product launch to get it in?


GeVng Lost in a Changing Process

Rule #3: Don’t Adopt an “Agile” Process


“If ader 15 minutes, you are s(ll in your standup,

here’s your sign.” – if Jeff Foxworthy was a programmer



Agile has real meaning! You can’t just make parts of the process up as you go along.

You do that when you walk blindly.


Mee(ng my contractual obliga(ons =) 20

Don’t throw out Jira

Have a reason for change

Rule #4: You Aren’t the Center of the World


“You are not special. You are not a beau(ful or unique snowflake.”

-‐ Tyler Durden, Fight Club



If you are crea(ng process alone…

Without QA, project managers, product owners…

You will forget things.

And you now own something else, adding even more to your workload.



Involve the team from the beginning.

Share responsibili(es.

Automate Everything & DRY

Rule #5: Don’t make it up as you go along


“We’ll make it up as we go along.” -‐ Me, at some point before the project started



A process should mean less work. A new process is like a new product.

Crea(ng a new process violates rule #1.

Develop one product at a (me.



“There’s never enough (me to do it right, but there’s always enough

(me to do it over.” – Jack Bergman


Changes in Technology “Some people, when confronted with a problem, think "I know, I'll use regular

expressions." Now they have two problems.” -‐  Jamie Zawinski

Rule #6: Treat Technology Change as an Op(miza(on


Your exis(ng stack got you there It’s not old, it’s baele-‐tested!



Validate Changes

You do it for Product

You do it for Process

You do it for Code

We should do it for

Technology Choices



“We should forget about small efficiencies, say about 97% of the Fme: premature op6miza6on is the root of

all evil” – Donald Knuth, or Tony Hoare, or not?

Rule #7: Prefer Proven Technologies, Seek New Solu(ons


“Before adop(ng new technology, Toyota will go to great lengths to analyze the impact

it may have on exis(ng processes.” -‐ Jeffrey Liker, The Toyota Way

Rule #7: Prefer Proven Technologies, Seek New Solu(ons


What problem does the new solu(on solve that the proven technology not?

Is that problem real?

Adopt new technology with small steps.

Rules Recap


1. Develop one product at a (me

2. Encourage a Minimal Viable Product

3. Don’t adopt an “agile” process 4.  You aren’t the center of the world 5.  Don’t make it up as you go along

6. Treat technology changes as an op(miza(on

7. Prefer proven technologies, seek new solu(ons


Thank you

@jasonlo(to

How we killed our process, technology stack, and assumptions – and survived

Technology

Transcript of How we killed our process, technology stack, and assumptions – and survived