Scaling Software Development: Teams & Codebase

by Tutti Quintella

Slide 1

Slide 1 text

Scaling Software Development Teams & Codebase

Slide 2

Slide 2 text

Who am I? ● Tutti Quintella (@tuttiq) ● From São Paulo, Brazil ● Computer Engineering major ● Software Engineer since 2011

Slide 3

Slide 3 text

DEAR WOMEN, WE NEED YOU HAVE PIZZA!

Slide 4

Slide 4 text

MERCARI, THE SELLING APP!

Slide 5

Slide 5 text

My trajectory ● From Brazil, to London, to Tokyo ● From 15-people startups to multinational companies with more than 400,000 employees ● Teams from 3 to 13 members ● From a simple web page to complex multi-app platforms ● Software for 6, 300, 5000 or millions of users

Slide 6

Slide 6 text

Disclaimer ● This presentation touches controversial topics like: ○ Team structures ○ Development process ○ Code readability ○ Design patterns / "best practices" ● A lot of the content is opinion based and subjective to exceptions / counter-arguments

Slide 7

Slide 7 text

GET THE SLIDES ● This presentation touches controversial topics like: ○ Team structures ○ Development process ○ Code readability ○ Design patterns / "best practices" ● A lot of the content is opinion based and subjective to exceptions / counter-arguments

Slide 8

Slide 8 text

Working in a software project 1. Write code 2. Commit changes and push to your repository 3. Deploy 4. It's live! Icons made by Freepik from www.flaticon.com

Slide 9

Slide 9 text

Let's add some complexity

Slide 10

Slide 10 text

Let's add some complexity Me

Slide 11

Slide 11 text

Let's add some complexity Me Maria

Slide 12

Slide 12 text

Scaling the problem... Conflict Inconsistency Redundancy ? ? ? ? Bug Rachel Joey Monica Ross Phoebe Chandler Me

Slide 13

Slide 13 text

Problem snowball ● Unstable system ● Complexity keeps increasing ● High stress, low productivity ● Technical debt building up ● Long time to ramp up new developers

Slide 14

Slide 14 text

How to scale efficiently? ● Reducing knowledge sharing bottleneck ○ Organized and intuitive codebase ○ Documentation ● Quality assurance ● Automation of repetitive tasks ● Structured teams & processes

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Scaling the codebase ● System design ● Coding style guide ● Best practices Image copyright by HBO - Silicon Valley

Slide 17

Slide 17 text

Scaling the codebase ● System design ● Coding style guide ● Best practices

Slide 18

Slide 18 text

System design: Design patterns ● Splitting the code into smaller parts ● More defined responsibilities ● Well known patterns: easier to find people that already know them, or easier to find learning resources

Slide 19

Slide 19 text

System design: Design patterns - MVC Image copyright by Sandro Mancuso at Codurance

Slide 20

Slide 20 text

Sometimes only M, V and C is not enough... ● Fat Controllers ● Fat Models ● Too much logic in one place

Slide 21

Slide 21 text

System design: Problems of fat components ● Harder to find logic when looking at the file structure ● Harder to read and understand what a component does ● Components are too specific and less reusable ● Harder to break the app in separate modules ● Harder to unit test

Slide 22

Slide 22 text

System design: First advice "Skinny controllers, fat models" Result: Skinny controller, OBESE models. User.rb - 700+ lines...

Slide 23

Slide 23 text

System design: Second advice ● Mixins: pulling logic out of a component into a module/interface ● Does it really organize your code?

Slide 24

Slide 24 text

System design: Ways to extract logic ● Mixins (properly implemented) ● Value objects ● Service objects ● Policy objects ● Form objects ● Query objects

Slide 25

Slide 25 text

System design: Ways to extract logic ● Mixins (properly implemented) ● Value objects ● Service objects ● Policy objects ● Form objects ● Query objects Refactoring Fat Components

Slide 26

Slide 26 text

System design: Architecture microservices.io

Slide 27

Slide 27 text

Scaling the codebase: Code organization ● System design ● Coding style guide ● Best practices

Slide 28

Slide 28 text

Coding style guide: Why? ● Inconsistencies in the code format make development inefficient: ○ Am I supposed to include className or class_name? ○ Is sampleNumber a variable or a constant? ○ Is this code inside this method/class/block or is it just an indentation inconsistency?

Slide 29

Slide 29 text

Code organization: Style Guide Indent by 2 spaces at a time. (Google HTML/CSS Style Guide)

Slide 30

Slide 30 text

Code organization: Style Guide Avoid single line methods. (The Ruby Style Guide)

Slide 31

Slide 31 text

Scaling the codebase: Code organization ● Design patterns ● Coding style guide ● Best practices

Slide 32

Slide 32 text

Best practices: Single Responsibility Principle A class / method / component should have only one responsibility

Slide 33

Slide 33 text

Best practices: DRY - Don't Repeat Yourself If you are copying and pasting the same thing with little alteration, it could probably be a reusable function / module / plugin...

Slide 34

Slide 34 text

Code organization: Best practices Many others…. ● The Boy Scout Rule ● Avoid premature optimization ● KISS - Keep It Simple Stupid

Slide 35

Slide 35 text

How to scale efficiently? ● Reducing knowledge sharing bottleneck ○ Organized and intuitive codebase ○ Documentation ● Structured teams & processes ● Quality assurance ● Automation of repetitive tasks

Slide 36

Slide 36 text

Documentation: Code Annotation

Slide 37

Slide 37 text

Documentation: Code Annotation

Slide 38

Slide 38 text

Documentation: Code annotation to Wiki-style

Slide 39

Slide 39 text

Documentation: Human-made Wiki

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Quality Assurance: Tests ● Unit / integration tests ○ Confidence in making changes without breaking working code My big refactor

Slide 42

Slide 42 text

Quality Assurance: Monitoring ● Monitoring real-time problems Image from Newrelic.com

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Automation: CI / CD ● Continuous Integration ● Continuous Delivery https://jenkins.io/artwork/

Slide 45

Slide 45 text

Automation: Code review ● Linters, safety checkers, etc

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Teams & processes: Problems ● Everyone touching the same codebase ● Everyone discussing the same domain ● Everyone working across all technologies and business logic ● Lack of boundaries & roles ⇒ big mess

Slide 48

Slide 48 text

Teams & processes: Teams structure ● Teams with more than 5~6 people tend to organically split into smaller groups ○ Insecurities about sharing things with everyone ○ Too much context from too many sides, it's hard to absorb

Slide 49

Slide 49 text

Teams & processes: Teams structure ● Meetings with more than 5~6 people tend to have a max of 2-3 active participants ○ Insecurity about speaking to everyone ○ Hard to find a break to jump in the conversation ○ Takes longer to reach any conclusion ○ Redundancy of opinions

Slide 50

Slide 50 text

Teams & processes: Roles and Rules ● Processes and standards that everyone follows ○ PR / Ticket / Docs workflow and templates ○ Project / Sprint cycle ● Defined roles and tasks that everyone should do ○ Code cleanup? Code review? Releases? ● Task assignment strategy ○ Self-assigned or manager assigned?

Slide 51

Slide 51 text

Teams & Processes: Teams structures ● Ways of structuring teams Project A Project B Business domain A Business domain B

Slide 52

Slide 52 text

Teams & Processes: Teams structures ● Ways of structuring teams Project A Project B Service A Service B

Slide 53

Slide 53 text

Teams & Processes: Information sharing

Slide 54

Slide 54 text

Last but not least ● Knowledge sharing ● Teamwork feeling ● Communication

Slide 55

Slide 55 text

How to scale efficiently ● Reducing knowledge sharing bottleneck ○ Organized and intuitive codebase ○ Documentation ● Quality assurance ● Automation of repetitive tasks ● Structured teams & processes ✔ ✔ ✔ ✔ ✔ ✔

Slide 56

Slide 56 text

THANK YOU Contact: ● Email: [email protected] ● Facebook: https://fb.me/tuttiquintella ● Twitter / Github: @tuttiq ● LinkedIn: https://linkedin.com/in/tuttiq