Scaling Software Development: Teams & Codebase

Setup your environment, write code, commit, push and deploy, simple like that. When you are working alone, on a small project. When the development team and the codebase start to grow, things need to change.
This talk is about the challenges of scaling software development, multiplying team size and system complexity, and some strategies to deal with them. Including but not limited to: team sizes, code organization, quality assurance and automation.

This talk was a presented at the following events:
- Women Who Code Manila Tech Summit 2018
- Women Who Code CONNECT SF 2019

Transcript

1. Scaling Software
   Development
   Teams & Codebase
   

   View Slide

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

   View Slide

3. DEAR WOMEN, WE NEED YOU HAVE PIZZA!
   

   View Slide

4. MERCARI, THE SELLING APP!
   

   View Slide

5. 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
   

   View Slide

6. 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
   

   View Slide

7. 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
   

   View Slide

8. 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
   

   View Slide

9. Let's add some complexity
   

   View Slide

10. Let's add some complexity
    Me
    

    View Slide

11. Let's add some complexity
    Me Maria
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

18. 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
    

    View Slide

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

    View Slide

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

    View Slide

21. 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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

26. System design: Architecture microservices.io
    

    View Slide

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

    View Slide

28. 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?
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

33. 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...
    

    View Slide

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

    View Slide

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

    View Slide

36. Documentation: Code Annotation
    

    View Slide

37. Documentation: Code Annotation
    

    View Slide

38. Documentation: Code annotation to Wiki-style
    

    View Slide

39. Documentation: Human-made Wiki
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

45. Automation: Code review
    ● Linters, safety checkers, etc
    

    View Slide

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

    View Slide

47. 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
    

    View Slide

48. 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
    

    View Slide

49. 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
    

    View Slide

50. 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?
    

    View Slide

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

    View Slide

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

    View Slide

53. Teams & Processes: Information sharing
    

    View Slide

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

    View Slide

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

    View Slide

56. THANK YOU
    Contact:
    ● Email: tutti@womenwhocode.com
    ● Facebook: https://fb.me/tuttiquintella
    ● Twitter / Github: @tuttiq
    ● LinkedIn: https://linkedin.com/in/tuttiq
    

    View Slide