The Code was the Easy Part: Introducing an iOS Library at a Corporate

Slide 1

Slide 1 text

THE CODE WAS   THE EASY PART Introducing an iOS Library at a Corporate @samjarman #DevWorld

Slide 2

Slide 2 text

NEW YEAR  HU DIS • Sam Jarman • iOS Apps Since 2009 • Full time iOS 2018/2019 • Polyglot Programmer • Currently writing JS full time @samjarman  #DevWorld

Slide 3

Slide 3 text

@samjarman #DevWorld TODAY • This is a talk about software engineering • Problems with existing code and processes • Introducing a iOS UI Framework • The mindset changes • The lessons learned

Slide 4

Slide 4 text

@samjarman #DevWorld SOFTWARE  ENGINEERING Software engineering is   multi-version, multi-person   programming

Slide 5

Slide 5 text

@samjarman #DevWorld SOFTWARE  ENGINEERING Software engineering is   multi-version, multi-person   programming

Slide 6

Slide 6 text

@samjarman #DevWorld ACME • Two applications: • App A • App B

Slide 7

Slide 7 text

@samjarman #DevWorld TEAM MAKE UP Android  Dev Android  Dev iOS  Dev iOS  Dev Tester Tester Biz Analyst Product Owner Android  Dev Android  Dev iOS  Dev iOS  Dev Tester Tester Biz Analyst Product Owner Android  Dev Android  Dev iOS  Dev iOS  Dev Tester Tester Biz Analyst Product Owner

Slide 8

Slide 8 text

@samjarman #DevWorld Android  Dev Android  Dev iOS  Dev iOS  Dev Tester Tester Biz Analyst Product Owner Android  Dev Android  Dev iOS  Dev iOS  Dev Tester Tester Biz Analyst Product Owner Android  Dev Android  Dev iOS  Dev iOS  Dev Tester Tester Biz Analyst Product Owner FEATURE A FEATURE B FEATURE C

Slide 9

Slide 9 text

Slide 10

Slide 10 text

@samjarman #DevWorld

Slide 11

Slide 11 text

@samjarman #DevWorld CODE BASE App A App B “Common” (and more)

Slide 12

Slide 12 text

@samjarman #DevWorld View Business  Logic Model APIs WHAT WAS SHARED? App A App B Common

Slide 13

Slide 13 text

@samjarman #DevWorld if appA {} else {}

Slide 14

Slide 14 text

@samjarman #DevWorld

Slide 15

Slide 15 text

@samjarman #DevWorld TESTING • If you changed “common” • Testers had to test the other app (manual) • Without context / cases / SLA cases • Without an expectation for what is normal • Doing the process without an impact on quality

Slide 16

Slide 16 text

@samjarman #DevWorld We realised we were performing a process without impact on quality.

Slide 17

Slide 17 text

@samjarman #DevWorld Don’t share features across apps   unless they’re never ever going to change between apps. LESSON 1

Slide 18

Slide 18 text

@samjarman #DevWorld Time for a change.

Slide 19

Slide 19 text

@samjarman #DevWorld We are working towards a Target State   Architecture. MINDSET   SHIFT

Slide 20

Slide 20 text

@samjarman #DevWorld Target State   Architecture   (TSA) • An agreement of what our codebase would look like without tech debt • What if it would look like if we built it today • What we want to get to • Check each time if a change is towards or away from TSA

Slide 21

Slide 21 text

@samjarman #DevWorld • Try this at your own company • Take half a day with your engineers to think what perfection would look like • Maybe it’s micro-services, modularisation, etc. • Come back with a plan • Stick it on the wall, refer to it   again and again Target State   Architecture   (TSA)

Slide 22

Slide 22 text

@samjarman #DevWorld Take the time to make sure   your team agrees on the target   state architecture. LESSON 2

Slide 23

Slide 23 text

@samjarman #DevWorld Sharing what is   truly common.

Slide 24

Slide 24 text

@samjarman #DevWorld View Business  Logic Model APIs WHAT WAS SHARED? View Business  Logic Model APIs App A App B Common  (and more)

Slide 25

Slide 25 text

@samjarman #DevWorld THE GOAL App A App B Styleguide Styleguide Utils Utils API API

Slide 26

Slide 26 text

@samjarman #DevWorld We are now making   code for our teammates to use. MINDSET   SHIFT

Slide 27

Slide 27 text

@samjarman #DevWorld THE START • We’d start with a UI Library   – “StyleGuide” • Needed to prove the concept to ourselves and internally • No time from the business for this – a secret skunkworks project

Slide 28

Slide 28 text

@samjarman #DevWorld The initial build.

Slide 29

Slide 29 text

@samjarman #DevWorld CONTAINED: • Cocoa Touch Framework • UIKit Subclasses • Fonts • Colours • Typography • Some view controllers

Slide 30

Slide 30 text

@samjarman #DevWorld STYLE GUIDE  COMMITTEE • Four Devs – two devs from each app group • Our iOS designer

Slide 31

Slide 31 text

@samjarman #DevWorld BUILD   TIME • Built the framework in a few hours • Moved over most   existing components • Renamed • Fixed imports • Got it building

Slide 32

Slide 32 text

@samjarman #DevWorld Donezo! Right?

Slide 33

Slide 33 text

@samjarman #DevWorld Wrong.

Slide 34

Slide 34 text

@samjarman #DevWorld The proof of concept   is the easy part. LESSON 3

Slide 35

Slide 35 text

@samjarman #DevWorld “Now, ﬁnish it.”

Slide 36

Slide 36 text

@samjarman #DevWorld THE LONG   TAIL BUILD Sketch Files Swift Files • Build complex TableView rows • Buttons • Text Fields

Slide 37

Slide 37 text

@samjarman #DevWorld DISCUSSIONS • Nut out API design • Component boundaries • Naming schemes • Best practices • Wrote up documentation for chapter

Slide 38

Slide 38 text

@samjarman #DevWorld (Like these slides before @HelloMissPotter helped me out.) The goal of the StyleGuide   was to not let developers create something ugly.

Slide 39

Slide 39 text

@samjarman #DevWorld API DESIGN • Alloc init with? • Dequeue and setup()? • Factory? • Conﬁg objects? • Builder pattern? • Getters and setters for everything?

Slide 40

Slide 40 text

@samjarman #DevWorld SETUP() • Init’d by you, or by tableview/collectionview • Setup took args that gave strings, ﬂourishes • For complex args, we’d use conﬁg objects (structs) • If you can pass in an arg set, it should support it • Optionals were API  Eg: Optional subtitles (string?)

Slide 41

Slide 41 text

@samjarman #DevWorld COMPONENT BOUNDARIES • A ﬁrst attempt at this was something known as a “Flexi-Cell” • A super conﬁgurable cell • Hard to edit • Easy to use • Trivial to make something ugly

Slide 42

Slide 42 text

@samjarman #DevWorld BEST PRACTICES Use Optionals Produce a Cell version Don’t move to SG if just for your app Ask for help Variation or new component Push back on design if new Test it yourself Collab with designers Straight to master Ask around to avoid duplication If the API won’t let you, don’t

Slide 43

Slide 43 text

@samjarman #DevWorld Think of the advice and   mindset you had and   document it for others. LESSON 4

Slide 44

Slide 44 text

@samjarman #DevWorld NAMING • AccountSummaryView • IconTitleSubtitleView • FourDataView • Preﬁx? Yes no? • Cell vs View name?

Slide 45

Slide 45 text

@samjarman #DevWorld ARBITRARY • No one right way • Went with what makes sense • Debate and commit

Slide 46

Slide 46 text

@samjarman #DevWorld SOLVING   ARGUMENTS • Arguments are common • Often leave people feeling disengaged, angry or resentful • It’s simpler than you think?

Slide 47

Slide 47 text

@samjarman #DevWorld Give all evidence  Hear all evidence LESSON 5

Slide 48

Slide 48 text

@samjarman #DevWorld And everything went great after that.

Slide 49

Slide 49 text

@samjarman #DevWorld The End

Slide 50

Slide 50 text

@samjarman #DevWorld um…there were some problems.

Slide 51

Slide 51 text

@samjarman #DevWorld THE   PROBLEMS • Committee got gatecrashed • Other team members weren’t   told of impact • Low Buy-in • New hires • Poor knowledge of modules

Slide 52

Slide 52 text

@samjarman #DevWorld HOW THE   SAUSAGE   IS MADE • A team member once gate crashed a meeting • “I just want to see how the sausage is made.” • What was our impression?   Fun? Cowboys? Malicious?

Slide 53

Slide 53 text

@samjarman #DevWorld Employ empathy to   see how your work   might be perceived. LESSON 6

Slide 54

Slide 54 text

@samjarman #DevWorld SOLVING IT • More outwards communication • Weekly updates • More documentation • A bit more training/walkthroughs • Pairing on tasks

Slide 55

Slide 55 text

@samjarman #DevWorld • Opened up committee meetings • We had to explain everything • Debates re-visited • Work undone • Progress halted NOT  SOLVING IT

Slide 56

Slide 56 text

@samjarman #DevWorld Not all code we're working on is for our team’s feature. MINDSET   SHIFT

Slide 57

Slide 57 text

@samjarman #DevWorld We got momentum as a team of   teams when we looked to make   common components as   we built individual features. LESSON 7

Slide 58

Slide 58 text

@samjarman #DevWorld OTHER TEAM   MEMBERS • BAs • Product Owners • Testers • #

Slide 59

Slide 59 text

@samjarman #DevWorld BUSINESS   ANALYSTS • BAs at ACME are scrum masters • Wanted to know how to size stories • Dependants/Dependencies • Solved quite easily with conversation

Slide 60

Slide 60 text

@samjarman #DevWorld PRODUCT   OWNERS • Ultimately own the teams time at ACME • Goal is products out the door • Had to be convinced that internal tooling would pay off in the long run • Solved by pointing out this is standard practice already at ACME • Saw beneﬁts of the process for ACME as a whole

Slide 61

Slide 61 text

@samjarman #DevWorld Think about what mental models people might have for their own roles. LESSON 8

Slide 62

Slide 62 text

@samjarman #DevWorld PROBLEMS:  TESTERS • Not developers at ACME • Wanted to know what to test • How to test it • Where to test it

Slide 63

Slide 63 text

@samjarman #DevWorld • StyleGuide Test App • Test it in that • All scenarios displayed • Test it in both apps* SOLUTIONS:  TESTERS

Slide 64

Slide 64 text

@samjarman #DevWorld Our phase one was just a   smaller shared library. We didn’t   have a true dependency yet.

Slide 65

Slide 65 text

@samjarman #DevWorld A new, smaller co-dependency isn’t an external dependency. LESSON 9

Slide 66

Slide 66 text

@samjarman #DevWorld MODULARISATION   PROJECT • Our work was noticed! Positively! • Leadership decided we should push forward with TSA and modularise properly • It was time for a…

Slide 67

Slide 67 text

@samjarman #DevWorld ~*Dependency Manager*~

Slide 68

Slide 68 text

@samjarman #DevWorld If you want to ﬁght with an iOS Developer, just say your favourite dependency manger on ‘three’

Slide 69

Slide 69 text

@samjarman #DevWorld DEPENDENCY   MANAGER • CocoaPods? • Carthage? • Git sub-modules/subtrees? • Swift Package Manager?

Slide 70

Slide 70 text

@samjarman #DevWorld • Went with Carthage • Corporate Networks • Ease of Use • Ease of Changing Mind Later DEPENDENCY   MANAGER

Slide 71

Slide 71 text

@samjarman #DevWorld Take the time,   do the research. LESSON 10

Slide 72

Slide 72 text

@samjarman #DevWorld What worked at your last company might not work at the next. LESSON 11

Slide 73

Slide 73 text

@samjarman #DevWorld Solving the   Testing Problem

Slide 74

Slide 74 text

@samjarman #DevWorld Semantic versioning. MINDSET   SHIFT

Slide 75

Slide 75 text

@samjarman #DevWorld X.Y.Z • X = Major Version. • Breaking Changes. Non-compatible. • Y = Minor versions. • Additions and deprecations. • Z = Patch versions • Under the hood changes. Bug ﬁxes. SEMANTIC  VERSIONING

Slide 76

Slide 76 text

@samjarman #DevWorld Semantic versioning is about much   more than a fancy number system.    It’s about making a promise to   your consumers.

Slide 77

Slide 77 text

@samjarman #DevWorld 1.2.1 → 1.2.2  I promise not to break your   code in this version.

Slide 78

Slide 78 text

@samjarman #DevWorld 1.2.1 → 1.3.0  I promise you’ll see new stuff in this   version, but it won’t break old stuff.

Slide 79

Slide 79 text

@samjarman #DevWorld 1.2.1 → 2.0.0  Somethings gonna break.

Slide 80

Slide 80 text

@samjarman #DevWorld SEMANTIC  VERSIONING • Two Promises • Code API Promise • Visual Promises A STYLEGUIDE

Slide 81

Slide 81 text

@samjarman #DevWorld PROCESS  CHANGES • This was a big mindset change for a lot of the developers • Upfront thinking about versioning threw some people • Testing ﬁt into this…how?

Slide 82

Slide 82 text

@samjarman #DevWorld • More testing by developers before handing it off • Testers not equipped to test if SemVer was correct • SemVer being correct was important PROCESS  CHANGES

Slide 83

Slide 83 text

@samjarman #DevWorld • “I don’t see how I wouldn’t have to   test both apps?” • “How can I prove my code is correct before integrating it?” • “Who updates it if we get too   far behind?” • “Wait, why do I not have to test   both apps?” PROCESS  CHANGES

Slide 84

Slide 84 text

@samjarman #DevWorld Pushing Code   vs   Pulling Code MINDSET   SHIFT

Slide 85

Slide 85 text

@samjarman #DevWorld • Old code / mindset / processes / training was Push. • You made a change to something common, it was forced into the other app at compile time. • Therefore, while making the change, you have to test that push scenario. PUSH VS PULL

Slide 86

Slide 86 text

@samjarman #DevWorld • New process was pull • You would pull in a new update and that would come with a promise of visual and code compatibility • You, then and there, would have to resolve those changes PUSH VS PULL

Slide 87

Slide 87 text

@samjarman #DevWorld What may be an obvious   way of working to you might be dramatically new to others. LESSON 12

Slide 88

Slide 88 text

@samjarman #DevWorld "What if you couldn't get out of   your chair and ask questions   or give advice?”

Slide 89

Slide 89 text

@samjarman #DevWorld Internal Dependency External Mindset MINDSET   SHIFT

Slide 90

Slide 90 text

@samjarman #DevWorld COMMS • Great README • Great SemVer discipline • Great change log • Great/Clear API • Great documentation • samjarman.co.nz/dxguide

Slide 91

Slide 91 text

@samjarman #DevWorld Good communication is how you scale. LESSON 13

Slide 92

Slide 92 text

@samjarman #DevWorld And so, we went on.

Slide 93

Slide 93 text

@samjarman #DevWorld Happily   Ever   After! • SemVer clicking with most • We made multiple new versions per week (decreasing) • We introduced another couple   of dependencies • On our way TSA

Slide 94

Slide 94 text

@samjarman #DevWorld SOFTWARE  ENGINEERING Software engineering is   multi-version, multi-person   programming

Slide 95

Slide 95 text

@samjarman #DevWorld He aha te mea nui o te ao? He tāngata, he tāngata, he tāngata. What is the most important thing in   the world? It is people, it is people,   it is people.

Slide 96

Slide 96 text

THE CODE WAS   THE EASY PART Introducing an iOS Library at a Corporate @samjarman #DevWorld

Slide 97

Slide 97 text

@samjarman #DevWorld Thanks!