Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Scaling Software Development: Teams & Codebase

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

Tutti Quintella

November 24, 2018
Tweet

More Decks by Tutti Quintella

Other Decks in Programming

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: [email protected]
    ● Facebook: https://fb.me/tuttiquintella
    ● Twitter / Github: @tuttiq
    ● LinkedIn: https://linkedin.com/in/tuttiq

    View Slide