Real world software launch
Download as PPTX, PDF0 likes375 views
The document outlines the lifecycle of software development and launch, detailing workflows for both pre-senior design and senior design projects. It discusses various types of software, the significance of properly launching software, and the challenges that arise post-launch, such as bugs and failure to meet requirements. The narrative includes a real-world example illustrating the importance of thorough testing and responsibility in fixing issues after deployment.
Real world software launch
- 1. REAL WORLD SOFTWARE LAUNCH CSCI 196 / 4244 INSTRUCTOR: KUNAL JOHAR
- 2. WORKFLOW (PRE-SENIOR DESIGN) • Receive assignment • Write pseudocode • Write program • Test Program • Submit • Then what?
- 3. WORKFLOW (SENIOR DESIGN) • Create assignment • Write pseudocode / bootcamp • Write program • Test program (how)? • Present program • Then what?
- 4. TYPES OF SOFTWARE • What are the different kinds of software that we see in the field?
- 5. TYPES OF SOFTWARE •Web Apps •Mobile Apps •Desktop Apps •Real-time Apps •Mainframe Apps
- 6. LAUNCHING SOFTWARE •What does it mean to launch software?
- 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
- 12. PERFECT SOFTWARE •Perfect software has no bugs •What are some examples of perfect software?
- 13. LIST OF PERFECT SOFTWARE (this slide was intentionally left blank)
- 14. SOFTWARE LAUNCH (NAÏVE METHOD) •Write Code •It Compiles, •Start Shipping! •What could possibly go wrong?
- 15. POST LAUNCH PROBLEMS •Scalability Issues •Bugs / Crashes •Failure to meet original requirements •Anything else?
- 16. POST LAUNCH PROBLEMS •It doesn‟t scale! •ToVieFor, Inc – TechCrunch Finalist (Really miserable people to work with)
- 17. POST LAUNCH PROBLEMS •Their website now…
- 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?)
- 26. FIXING OUR PROGRAM •Let‟s revisit and old friend
- 27. FIXING OUR PROGRAM •Where am I being launched?
- 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”
- 30. VERSION 1 LAUNCHED! … :)
- 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!”
- 32. BUG REPORTS
- 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
- 41. ACCOUNTABILITY •“Just in case” • I order pizza • Heather brought wine •Why did we each do this?
- 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?