"product architecture: failures and lessons learnt" - royi benyossef @products_of_things,...

Product architectureby Royi Benyossef

Failures and lessons learnt

Android developer since 2009Tech community activist, speaker and founderMentor at * acceleratorGoogle expert since 2013Developer relations manager Samsung Next Tel-Aviv

Introduction Royi Benyossef

Introduction Samsung Next Tel-avivCommunity (free-for-all, no strings attached) Investment:

Early stage SW & SaaS startupsSeasoned entrepreneursDeep tech - IoT, AR/VR, cyber, DL, ML, CV,

bots, cloud etc.

Community (free-for-all, no strings attached) Investment (SW & SaaS startups & entrepreneurs) For more information:- samsungnexttlv.com- royi@samsungnext.com

Introduction Samsung Next Tel-aviv

Prolog

Prolog

Vidmind:Introduction

Prolog

Vidmind:- End-to-end OTT TV

platform

Introduction

Prolog

Vidmind:End-to-end OTT TV platform- Standard backend & clients

Introduction

Prolog

Vidmind:End-to-end OTT TV platform- Standard backend & clients

+ AOSP STB

Introduction

Prolog

Vidmind:End-to-end OTT TV platform- Standard backend & clients

+ Android “based” set-top box

Introduction

Prolog

AOSP STBMe @ Vidmind:

Introduction

Prolog

AOSP STBMe @ Vidmind:

- From Android tech. leader

Introduction

Prolog

AOSP STBMe @ Vidmind:

From Android tech. leader- To Android clients

group manager

Introduction

Prolog

AOSP STBMe @ Vidmind:

From Android tech. leader- To Android clients

group manager(In charge W/ design, dev, arch. & prod.)

Introduction

Prolog

See what we didAgenda

Prolog

See what we didTalk about what went wrong and why

Agenda

Prolog

See what we didTalk about what went wrongSay what we learned from our issues

Agenda

Prolog

See what we didTalk about what went wrongSay what we learned from our issuesShow how we attempted to “fix it”

Agenda

Prolog

See what we didTalk about what went wrongSay what we learned from our issuesShow how we attempted to “fix it”Disclose how that panned out

Agenda

Prolog

See what we didTalk about what went wrongSay what we learned from our issuesShow how we attempted to “fix it”Disclose how that panned outRepeat

Agenda

Chapter 1To be young and hopeful

Chapter 1

One app (launcher) What we did

Chapter 1

One app (launcher)Each “screen” was in a transparent activity

What we did

Chapter 1

One app (launcher)Each “screen” was in a transparent activityRoot app handled video and OpenGL gallery

What we did

Chapter 1

One app (launcher)Each “screen” was in a transparent activityRoot app handled video and OpenGL galleryOn-prem and manual build machine

What we did

Chapter 1

One app (launcher)Each “screen” was in a transparent activityRoot app handled video and OpenGL galleryOn-prem and manual build machine Using proprietary APIs for “special” features

What we did

Chapter 1

Apk size was enormous What we later found

Chapter 1

Apk size was enormous (mostly bad for dev)

What we later found

Chapter 1

Apk size was enormous (mostly bad for dev)UX did not work as the designers asked

What we later found

Chapter 1

Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess

What we later found

Chapter 1

Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess:

> Builds took time and manpower

What we later found

Chapter 1

Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess:

Builds took time and manpower> No QA automation

What we later found

Chapter 1

Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess:

Builds took time and manpowerNo QA automation> Stability was terrible

What we later found

Chapter 1

Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess:

Builds took time and manpowerNo QA automationStability was terrible> Runtime memory was too

much

What we later found

Chapter 1

Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable mess:

Builds took time and manpowerNo QA automationStability was terrible> Runtime memory was too

much

What we later found

Max runtime =

~2 hours

Chapter 1

Apk size was enormous (mostly bad for dev)UX did not work as the designers askedCodebase became an unmanageable messQA was impossible

What we later found

Chapter 1

We can’t look at this as a normal application

What we learned from it

Chapter 1

We can’t look at this as a normal applicationWe need to seek other implementations

What we learned from it

Chapter 2Throwing a tantrum

Chapter 2

One appWhat we (almost) did

Chapter 2

One app Implemented entirely in OpenGL

What we (almost) did

Chapter 2

OpenGL development is long and hard

What we later found

Chapter 2

OpenGL development is long and hardOpenGL wrappers are meant for games

What we later found

Chapter 2

We have to go back!!!What we learned from it

Chapter 3Minimum changes

Chapter 3

Activities became apps What we did

Chapter 3

Activities became apps (1 per screen + launcher)

What we did

Chapter 3

Activities became apps (1 per screen + launcher)Added a “sticky” service

What we did

Chapter 3

Activities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces):

- App to service

What we did

Chapter 3

Activities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces):

App to service- Service to app

What we did

Chapter 3

Activities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces)Pseudo MVC

What we did

Chapter 3

Activities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces)Pseudo MVC* Still using OpenGL gallery

What we did

Chapter 3What we didActivities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces)Pseudo MVC* Still using OpenGL gallerySTB HW and FW updated to improve UX

Chapter 3What we didActivities became apps (1 per screen + launcher)Added a “sticky” service Communication (w/ interfaces)Pseudo MVC* Still using OpenGL gallerySTB HW and FW updated to improve UX (Incl. Android API upgrade)

Chapter 3

Services do not live foreverWhat we later found

Chapter 3

Services do not live forever (= instability)

What we later found

Chapter 3

Services do not live forevercomplex development process

What we later found

Chapter 3

Services do not live forevercomplex development process

(= 10 files to add a method)

What we later found

Chapter 3

Services do not live forevercomplex development processAll proprietary APIs changed behavior

What we later found

Chapter 3

Services do not live forevercomplex development processAll proprietary APIs changed behavior

(= needed massive code changes)

What we later found

Chapter 3

Services do not live forevercomplex development processAll proprietary APIs changed behaviorCode maintainability issues

What we later found

Chapter 3

Services do not live forevercomplex development processAll proprietary APIs changed behaviorCode maintainability issues+ builds (still) took time and manpower

What we later found

Chapter 3

Services do not live forevercomplex development processAll proprietary APIs changed behaviorCode maintainability issues+ builds (still) took time and manpower+ No QA automation

What we later found

Chapter 3

Services do not live forevercomplex development processAll proprietary APIs changed behaviorCode maintainability issues+ builds (still) took time and manpower+ No QA automation

= QA was impossible

What we later found

Chapter 3

No more OpenGLWhat we learned from it

Chapter 3

No more OpenGLWe need to work with Android, not against it

What we learned from it

Chapter 3

No more OpenGLWe need to work with Android, not against itWe need a great UX that works on Android

What we learned from it

Chapter 3

No more OpenGLWe need to work with Android, not against itWe need a great UX that works on AndroidBuild and QA automation are a must

What we learned from it

Chapter 3

No more OpenGLWe need to work with Android, not against itWe need a great UX that works on AndroidBuild and QA automation are a mustFeature encapsulation is a must

What we learned from it

Chapter 3

No more OpenGLWe need to work with Android, not against itWe need a great UX that works on AndroidBuild and QA automation are a mustFeature encapsulation is a mustEffective code sharing is a must

What we learned from it

Chapter 4This has to work!

Chapter 4

Maven + jenkins based build machine

What we did

Chapter 4

Maven + jenkins based build machineAppium + Espresso + JUnit automation

What we did

Chapter 4

Maven + jenkins based build machineAppium + Espresso + JUnit automationHAL

What we did

Chapter 4

Maven + jenkins based build machineAppium + Espresso + JUnit automationHAL (Hardware Abstraction Layer)

What we did

Chapter 4

Maven + jenkins based build machineAppium + Espresso + JUnit automationHAL (Hardware Abstraction Layer) Func. based encapsulation

What we did

Chapter 4

Maven + jenkins based build machineAppium + Espresso + JUnit automationHAL (Hardware Abstraction Layer) Func. based encapsulation App dependency management

What we did

Chapter 4

Far faster implementationWhat we later found

Chapter 4

Far faster implementationReduced inter-team dependency

What we later found

Chapter 4

Far faster implementationReduced inter-team dependency allowed us to:

- Increase group size to ~35

What we later found

Chapter 4

Far faster implementationReduced inter-team dependency allowed us to:

Increase group size to ~35- Work in 5 locations (4

countries)

What we later found

Chapter 4

Far faster implementationReduced inter-team dependencyDesigners were happy with the UX

What we later found

Chapter 4

Far faster implementationReduced inter-team dependencyDesigners were happy with the UXImproved performance and stability

What we later found

Chapter 4

Far faster implementationReduced inter-team dependencyDesigners were happy with the UXImproved performance and stabilityImproved work cycle and transparency

What we later found

Chapter 4

Far faster implementationReduced inter-team dependencyDesigners were happy with the UXImproved performance and stabilityImproved work cycle and transparencyHW&FW agnostic product:

What we later found

Chapter 4

Far faster implementationReduced inter-team dependencyDesigners were happy with the UXImproved performance and stabilityImproved work cycle and transparencyHW&FW agnostic product:

> Faster integ. for demos -> easier sale

What we later found

Chapter 4

Far faster implementationReduced inter-team dependencyDesigners were happy with the UXImproved performance and stabilityImproved work cycle and transparencyHW&FW agnostic product:

Faster integ. for demos -> easier sale

> Increased bargaining power with OEMs

What we later found

Summary

Summary

Work better not harderWhat we learned from it

Summary

Work better not harderAutomate as much as possible

What we learned from it

Summary

Work better not harderAutomate as much as possibleWork with your system, not against it

What we learned from it

Summary

Work better not harderAutomate as much as possibleWork with your system, not against it

(HW, SW, FW and people)

What we learned from it

Summary

Work better not harderAutomate as much as possibleWork with your system, not against itNever be afraid to start over (if you can)

What we learned from it

“We should be building great things. Things that Don’t yet exist”

Royi Benyossef samsungnexttlv.com

Hope you liked itThanks for listening!

Royi Benyossef

(royi@samsungnext.com)