Writing for software in school leaves out much of the true hassles in software development.
This brief lecture covers the hidden challenges when deploying to the real world.
7. LAUNCHING SOFTWARE
• Software Launches by Type
• Web Apps
• Mobile Apps
• Desktop Apps
• Real-time Apps
• Mainframe Apps
8. ….BACK TO SENIOR DESIGN
Scenario: You did a great job at the 100% presentation.
Afterwards, Chairman Youssef asks for a personal
demo. He points out a few flaws that he wants fixed
since you have been selected for the Pelton award.
Your Project: Recognize gestures using a web cam and
a special green marker you hold on your finger. The
software was set to look at RGB values with some
tolerance to detect and track the green marker
The problem: In your dorm room gestures worked just
fine, but in the CS room gestures were not often
recognized.
9. …BACK TO SENIOR DESIGN
• How would you tackle this problem?
• How would you implement the fixes?
• How would you show the fixes are
implemented?
10. …BACK TO SENIOR DESIGN
• Why did you implement the fix?
• For whom did you implement the fix?
11. …BACK TO SENIOR DESIGN
•This actually happened…(well almost)
•Solution
• Adam discovered the use of
Hue / Saturation Values in addition
to RGB values
18. POST LAUNCH PROBLEMS
•We‟ll get back to these…
• Bugs / Crashes
• Failure to meet original requirements
•How would we go about fixing problems
when they are out in the field?
19. FIXING PROBLEMS POST LAUNCH
Scenario: You are a software developer
assigned to a particular application that
has some reported bugs.
Who do you think is responsible for fixing
the bugs?
How do you think they get fixed?
20. FIXING PROBLEMS POST LAUNCH
•What does it mean to be fixed?
• Code fixed
• Fix regressively tested (how?)
• Fix deployed (how? and who?)
21. PROBLEMS…FIXING PROBLEMS
• Chain of Responsibility
• Developer and “Deployer” are usually
different people
• Development machine can have different
configuration than live environment
• Time is against you
• What time do software fixes get deployed?
• What happens from the time a bug is
discovered to fix?
• What if a bug isn‟t discovered for a long time?
22. SUPERMAN III
•Harmony Gateway
• Scheduling and Billing Software
• 400 students x 6 schools x lots of
transactions!
• Accrual based accounting system
(lots of records just to sign up for a month
of lessons)
•System deployed March 2007
23. SUPERMAN III
• WriteRevenueRecognizeJE()
• X = Total Lessons Cost
• C = Total Lesson Count
• For each lesson date D
• Recognize X/C revenue on D
• If DISCOUNT
• Output Discount JE
• WriteRevenueRefundJE()
• X = Total Lessons Cost
• C = Total Lesson Count
• For each lesson date D
• Recognize X/C revenue on D
• Bug Discovered August 2010…..
24. SUPERMAN III
•When lessons were refunded, discounts
were never “undone”
•Result, about $500,000 in income placed
in the wrong account
•I would have gotten fired but…
•Fortunately there was $500k EXTRA
25. HOW TO FIX PROGRAMS
•Understanding we can‟t deploy our fixes
directly how can we handle fixes for the
following platforms:
• Web
• Desktop
• Mobile App
• Real-time (e.g. Car / Avionics?)
28. FIXING OUR PROGRAM
• Yes, launching also be a huge hassle…
• Include app screenshots
• Include icons in 4 different sizes
• Generate a code signing certificate
• Have a website
• Ensure you are not violating the store
submission (vague) guidelines
• Submit
• Wait 7-14 days to find out if you have a
violation and need to wait another 7-14 days
• Pray
29. VERSION 1 LAUNCHED!
•“Yes, we‟re ahead of schedule!”
•“Getting through the app store details
was a hassle but, I‟m sure it all works”
31. VERSION 1 LAUNCHED! … :(
(5 voicemails left)
“Many reporters contacted and
(aka friends and my sister)
want to run a story but they can’t with all
these bugs!”
34. TRYING TO UNDERSTAND BUGS
•Try to walk through scenario
• Who sent the vote?
When did they send it?
• Then we try sending them (magically it
works)
•Check externalities
• Amazon for storage
• Urban Airship for push notifications
35. AVOIDING EGO
• “It works on my machine”
• Of course it does, you are the developer
• We like to think we can „prove‟ a problem is outside of our
purview
• If it doesn‟t work for the client, no amount of evidence will
be convincing
• The truth is, it is likely our fault
• When Apple/Amazon/API providers mess up there are
usually a lot of people who have problems
• StackOverflow it, otherwise take responsibility
• Worst is the time to deploy
• Client side bug fix to app store means another week
minimum of the bug existing
• We as developers have no control over this, but imagine the
point of view of the customers / users
36. WE HAD BIG EGOS
• Few problems
• Text labeling issues
• Amazon S3 interaction failures
• Privacy settings blocking push notifications
• But most of the problems were plain-ole
annoying
• “How come it send a text message when the
recipient doesn‟t have the app?
• To client bugs mean not meeting the “original
requirement” that was never there
37. VERSION 1 ISSUES
•Bugs
• Push notifications only work in free version
• Free version‟s ad is covering up
“Feedback”
• App says “Shopping with Friends” but
name is “Shopptique”
• Internet keeps “going out”
•Fixed in a series of updates V1.1 –
1.4, taking 4 full weeks
38. WE HAD BIG EGOS
• “I just want it to work, this needs to be like
texting and no one, not my sister, mom,
dad, anyone have gotten push notifications”
• Disbelief: Push notifications worked for
everyone in the office
• Bad luck: There was an cloud outage during
Christmas, nothing was working for anyone.
• How do you explain „cloud outage‟?
• “Aghh, I‟m very disappointed.” Push
notifications just don‟t work.
39. WE HAD BIG EGOS
•“Why don‟t you come to the office, we
have all of the development tools here
and can figure this out once and for all”
• Translation: Come here so we can belittle
you and show you never downloaded the
latest version
• Her Thoughts: Nice! Finally I get to call
their bluff on their worthless skill.
40. ACCOUNTABILITY….
•We have our 5 test devices and emulator
ready to go
•Heather comes to our office with 2
friends
•It is the moment of truth, we all fire up
the app
42. ACCOUNTABILITY
•Heather and Friend
• Push notifications don‟t work!
•All of our devices including 2 brand new
devices
• Everything works great….
•Looks like none of us were lying
•Whose fault? What are the next steps?
43. SOLUTION
•We have a “femtocell” at the office
•Presumed “bad internet connection” was
the reason, promised to research how
other apps get around the problem
•We knew that couldn’t be it….but we
were stumped and wanted her to leave
• Good thing we got pizza!
44. SOLUTION
• Found a better method to degrade on a
poor connection
• Discovered Push Notification Provider
(Urban Airship) “deactivated” devices that
had the original faulty push notification code
• Found a script to re-activate without
requiring to push an update to the app store
45. THE END?
•Called Heather
• Works for her!
• Works for her sister
• Works for her parents
• Works for her friends
• ….except this one friend
•Sigh….
• We asked for the friend‟s username
• Never got a response
46. WE KNOW BETTER THAN THIS…
•Web Programming Has Made Us Lazy
• Problems can be fixed instantly for
everyone
• We should do more testing, but can get
away with not
•What to do for all other software
• User acceptance testing
• Soft Launch
• Actual launch
47. SENIOR DESIGN AND BEYOND
http://www.joelonsoftware.com/articles/fog0000000067.html
Academia creates an environment where it is okay to
get the problem solved and move on. In the real
world, there is no excuse that this “is for research.”
Why did Heather not test her own app before
launching?
Why did we let her launch without testing?
What did it cost Heather to skip this step?
What did it cost us?
48. SENIOR DESIGN AND BEYOND
“Why do something when someone else will
take care of it?”
Will you lead by example for the sake of trying new
opportunities?
Will you wait for problems to arise and stagnate?
Worse, will you even realize you are stagnating?