AndroidTO deck

Building Software
in the Mobile Age
Chris Haseman

Chris Haseman Building Software in the Mobile Age
Wednesday, October 23, 13

What I’d like to talk about
‣ Patterns for developing and releasing Android software
‣ Tricks for designing and building beautiful software
‣ Ways we use to engage with our users and protect our

rating
‣ Why New Yorkers are so insufferable


Why should you care?


2 years at Tumblr
‣ Re-written from scratch
‣ From a web-view to fully native
‣ Crossed 10 million downloads
‣ From a 3.6 to 4.3 star application
‣ Mobile apps are now a signiﬁcant amount of Tumblr’s daily

trafﬁc


Development

Our Android Team
size matters not...
‣ Small Group (3 Full Time Developers)
‣ 1 Designer and 1 Production Designer
‣ 1 Pointy-Haired Manager (me)
‣ No in-house QA
‣ No Project or Product Managers


Developers should
work like managers...


Nope
optimizing for different goals
‣ Developers need large swaths of unscheduled time

managers break the day up into hourly chucks
‣ Meeting Windows: On Arrival, Before Lunch, After Lunch,

Just before end-of-day
‣ Developers should poll for new information while Managers

are interrupt driven. There is a large difference
‣ Be flexible when possible on meeting times

Scheduling is Easy!


Scheduling really is hard
it’s one of the toughest parts of software
‣ Programmers always estimate for the best case
‣ When planning, we think only of actually writing the code
‣ Few factor in changes, review, testing, or documentation
‣ Time padding for these is important, but BE CAREFUL
‣ “We’ll ship when it’s ready.” Only works for Blizzard
‣ “The developers set these dates!” is a cop-out


It’s ok to deliver a bit
late...


You’re as good as your word
as my father always irritated me by saying
‣ Trust is your only currency. No one understands what

you’re working on but you
‣ Gain it by hitting your dates, shipping features with no

surprises, and good communication
‣ Lose it by over or under estimating, sneaking in major

refactors, hiding or obfuscating bugs, or avoiding
responsibility
‣ Learn how to screw up well

Development
Maker vs Manager
Learn How to Schedule
Build and Maintain Trust


Side effects of doing this
well may include:
Leadership
Promotions
or Eventual Management

Design


The designs should be
ﬁnal before developers
build them


Designs are never ﬁnal
Good design requires dialog
‣ It’s not ﬁnished until it ships
‣ Remember, change requires TIME!
‣ Developers, it’s on you to call out major changes
‣ Pixel perfection is essential, but you should try to polish once
‣ Consistent, correct margins make the difference between

good applications and great ones


Designers: Customize
Everything
Developers: Customize
Nothing


Bad Managers:
“Make it look like the iPhone...”


Innovate on Purpose
Break the rules, learn them first
‣ 100% adherence to the standards defaults is boring
‣ 100% customization is confusing, particularly with navigation
‣ Designers, be aware of the costs of your customizations
‣ Developers, communicate time concerns
‣ Devs, never say “No”. Designers, never accept “No”.
‣ For Reference: One developer at Tumblr spends one week per

release on margins alone. We’re working on ﬁxing that.

Numbers aren’t essential...


Numbers are essential
Your gut is crap at making software
‣ Install Flurry, Localytics, Mixpanel, or Google Analytics
‣ Figure out how to track the behavior you want
‣ Check and see if you made positive user change
‣ Watch out for short term number bias
‣ Invest the time for good, consistent event tracking
‣ Numbers are your only weapon against bad ideas, especially

your own

Design
Communicate about Creativity
Customize often but with Care
Validate your Assumptions


Beautiful software
takes time, but the
payoffs are immense


The Market

Nothing beyond this point
is helpful unless you...


Do


not


build


shitty


android


applications


...seriously


Talk to your users!
the play store is the only tool you have
‣ A good rating requires building a community
‣ dump as much time into responding as possible
‣ learn everything you can from the 1-star reviews
‣ Remember those analytics? Use them to triage the rage
‣ at tumblr... the feels run strong


Mobile teams should be
deploying to production
constantly...


Nope
‣ Launch betas when feasible
‣ Do not take your beta testers or early adopters for granted
‣ Test before you release anything, internal or external
‣ Use Google’s staged roll-out
‣ Bugs will show up fast, keep a calm head but react quickly
‣ Bake. Your. Software. When it’s ready, put it in the oven for a

week


Rating Nags are Annoying


they are also effective
...incredibly effective
‣ Our daily average rating went from 3.6 to 4.5, overnight!
‣ Timing is everything catch people at a happy moment
‣ Be glib, positive, and friendly in your language
‣ Never ask them more than once in a 6 month period
‣ Ask for help, don’t demand it, but don’t beg for it either
‣ Your users are rooting for you, help them express it!

The Market
Engage your Users
Beta Test, Slow Roll, Watch
Ask your users to show
some love


Treat your users well,
and they will reward
you


I’m tired of developers
being black boxes


Programmers, learn to
communicate. As a
boss, help your
programmers get better
at it

I am sick of seeing
ugly Android software


It can be beautiful, spend
the time to make it so


I hate it when good
applications get a bad
name


Ask your users for help
when it’s appropriate.
Use data to recognize
and ignore the trolls


Lastly, I have some bad news...


Android development is Hard
You, in this room, help
eachother!


Make incredible things,
none of you has any
excuse to do otherwise


Thank you!
haseman@tumblr.com
haseman.tumblr.com
@haseman

AndroidTO deck

More Related Content

Viewers also liked (8)

Similar to AndroidTO deck (13)

Recently uploaded (20)

AndroidTO deck