AndroidTO deck

Chris Haseman Building Software in the Mobile Age

Building Software in the Mobile Age

Chris Haseman

Wednesday, October 23, 13


‣ 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

What I’d like to talk about



Why should you care?



‣ 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 significant amount of Tumblr’s daily traffic

2 years at Tumblr



Development



‣ 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

size matters not...Our Android Team



Developers should work like managers...



‣ 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

optimizing for different goalsNope



Scheduling is Easy!



‣ 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 one of the toughest parts of softwareScheduling really is hard



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



‣ 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

as my father always irritated me by sayingYou’re as good as your word



Maker vs ManagerLearn How to ScheduleBuild and Maintain Trust

Development



Side effects of doing this well may include:

LeadershipPromotions

or Eventual Management



Design



The designs should be final before developers

build them



‣ It’s not finished 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

Good design requires dialogDesigns are never final



Designers: Customize Everything

Developers: Customize Nothing



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



‣ 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 fixing that.

Break the rules, learn them firstInnovate on Purpose



Numbers aren’t essential...



‣ 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

Your gut is crap at making softwareNumbers are essential



Communicate about CreativityCustomize often but with Care

Validate your Assumptions

Design



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



‣ 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

the play store is the only tool you haveTalk to your users!



Mobile teams should be deploying to production

constantly...



‣ 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

Nope



Rating Nags are Annoying



‣ 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!

...incredibly effectivethey are also effective



Engage your UsersBeta Test, Slow Roll, Watch

Ask your users to show some love

The Market



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 HardYou, in this room, help

eachother!



Make incredible things, none of you has any

excuse to do otherwise



[email protected]

@haseman

Thank you!


mailto:[email protected]

mailto:[email protected]

AndroidTO deck

Technology

Transcript of AndroidTO deck